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A  STAND-ALONE  INFORMATION  SYSTEM  FOR  SMALL 
AIR  FORCE  HOSPITAL  LABORATORIES 

ABSTRACT  OF  THESIS 

Presented  to  the  Faculty  of  Trinity  University 
in  Partii.1  Fulfillment  of  the  Requirements 

For  the  Degree  of 

Master  of  Science 
Computing  and  Information  Sciences 

By 

Michael  P.  Fitch,  B.S.,  M.T.  (A.S.C.P. ) ,  C.L.S. 


For  almost  two  decades,  there  has  been  great  interest 
expressed  by  the  U.S.  Air  Force  and  the  Department  of  De¬ 
fense  in  using  computing  systems  to  automate  the  opera¬ 
tions  of  their  hospital  laboratories.  To  this  end,  sev¬ 
eral  projects  have  been  initiated.  The  results  have  pro¬ 
duced  extremely  large,  complex  systems  as  attempts  were 
made  to  develop  highly  integrated  methodologies  for  gen¬ 
eral  use  throughout  the  entire  military  hospital  commu¬ 
nity.  .^Consequently,  the  systems  are  still  not  fully  op¬ 
erational  ^r  are  unavailable  to  many  sites.  Even  if  these 


systems  were  currently  in  general  use,  their  utility  in 


small  laboratories  is  limited  due  to  the  lack  of 


accessibility  and  flexibility  these  large  systems  can  of¬ 


fer.  In  a  given  small  laboratory,  many  of  the  features 
may  never  be  used,  but  useful  functions  unique  to  the  lab¬ 
oratory  remain  unsupported. 

M 

- >  This  paper  discusses  the  use  of  microcomputers  run¬ 
ning  with  the  Microsoft  Disk  Operating  System  (MS-DOS)  as 
part  of  an  effective  solution  to  this  problem.  Proper 
analysis,  with  particular  attention  being  paid  to  the 
unique  requirements  of  each  user,  can  help  design  systems 
which  can  be  made  more  efficient  and  effective  for  the 
various  laboratories.  The  hardware  and  software  required 
to  fill  the  needs  of  the  small  laboratory  are  currently 
available  at  relatively  reasonable  cost.  _Jhese  "off-the- 
shelf"  systems  are  already  tested  and  supported  by  their 
developers.  Since  these  stand-alone  systems  are  intended 
to  be  augmentations  rather  than  replacements,  the  integra¬ 
tion  achieved  with  the  large,  general-purpose  systems  will 
not  be  minimized.  Even  for  microcomputers,  communication 
and  transfer  protocols  can  easily  be  established  and  im¬ 
plemented.  Above  all,  a  large  measure  of  flexibility  will 
be  introduced  into  the  total  computing  capabilities  of  the 
laboratory. 
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CHAPTER  I 

INTRODUCTION 

Scope  and  Objectives 

One  of  the  most  difficult  undertakings  for  a  manager 
of  a  modern  clinical  laboratory  in  an  Air  Force  hospital 
is  to  justify  and  ultimately  to  procure  up-to-date  equip¬ 
ment.  He  is  all  too  aware  of  its  availability  and  what  it 
can  do  to  help  him  streamline  the  operations  of  his  labo¬ 
ratory,  but  obtaining  the  ideal  instrument  seems  always  to 
be  beyond  his  reach.  Part  of  the  reason  for  this  lies  in 
the  multitude  of  laws  whose  purpose  it  is  to  protect  the 
government  while  at  the  same  time  satisfying  other  laws 
designed  to  assure  equal  opportunity  for  competing  civil¬ 
ian  businesses  [8,  pp.  9-12],  This  typically  creates  de¬ 
lays  which  eliminate  the  possibility  of  having  state-of- 
the-art  equipment  when  it  is  most  needed.  The  bulk  of  the 
remainder  of  the  reason  is  based  on  cost  in  any  of  several 
ways.  The  public's  demand  for  control  over  military 
medicine  has  resulted  in  strategies  to  track  and  document 


its  quality.  Much  time  and  money  has  been  spent  develop¬ 
ing  computing  systems  to  aid  this  effort. 

Hospital  quality  assurance  systems  are  not  new,  nor 
are  they  unique  to  the  military  [7,  p.  48],  Quality  con¬ 
trol  is  a  full-time  effort  for  any  hospital,  both  to  moni¬ 
tor  and  improve  patient  care  and  for  defensive  medicine*. 
The  military  medical  community,  however,  is  subject  to 
particular  scrutiny  by  Congress  and  by  the  public  in  gen¬ 
eral.  Much  of  the  justification  for  development  of  the 
large  hospital  computing  systems  has  been  political.  The 
systems  have  been  intended  to  provide  evidence  that  the 
quality  of  military  medicine  is  equivalent  or  superior  to 
civilian  medicine,  despite  highly  publicized  public  opin¬ 
ions  to  the  contrary.  The  success  of  the  system  is  mea¬ 
sured  by  the  familiar  civilian  criteria: 

(1)  Has  the  quality  of  care  improved?  (Or  at 
least,  have  the  reports  of  deficient  care  been 
reduced?) 

(2)  Has  the  cost  of  the  operation  been  reduced? 

The  requirement  for  military  hospitals  to  provide  ever-im¬ 
proving  care  at  lower  cost  is  not  unlike  the  goals  of 

^"The  term  "defensive  medicine"  is  commonly  used  to 
describe  as  a  group  the  routine  procedures  and  practices 
intended  to  provide  a  medical  entity  and/or  its  staff  with 
proper  and  sufficient  documentation  of,  and  justification 
for,  the  treatment  given.  These  practices  are  designed  to 
reduce  the  likelihood  of  lawsuits  against  the  medical  com¬ 
munity  and  also  serve  as  court  evidence  in  its  behalf. 
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civilian  institutions.  But  do  the  systems  also  enhance 
the  working  environment  of  the  grassroots  users,  here 
meaning  the  laboratory  staff?  At  least  one  system,  the 
Uniform  Charting  of  Accounts  (UCA) ,  has  even  been  detri¬ 
mental  . 

It  is  not  the  purpose  of  this  paper  to  address 
whether  these  systems  succeed  in  their  primary  goal,  i.e. , 
to  act  as  monitors  of  the  medical  community.  Rather,  the 
emphasis  will  be  on  augmenting  the  systems  to  help  the  lo¬ 
cal  laboratory  chief,  technologist,  or  technician  manage 
daily  work.  Although  the  software  systems  run  on  powerful 
computers,  they  do  essentially  only  the  function (s)  for 
which  they  were  designed.  Since  the  hardware  and  software 
are  necessarily  protected  and  quite  inaccessible,  repro¬ 
gramming  or  reconfiguring  the  system  to  meet  a  unique  or 
temporary  need  is  very  difficult,  if  not  impossible,  even 
for  those  individuals  who  are  capable  of  such  an  endeavor 
[16,  p.  3-13].  Much  of  the  capability  of  the  hardware  is 
lost  by  limiting  the  flexibility  of  the  system  to  only  the 
installed  software. 

The  objective  of  this  paper  is  to  show  that  the  real 
needs  of  the  local  laboratory  manager  can  be  much  better 
served  by  augmenting  the  large  laboratory  computers  with 
small,  independent  hardware/software  systems  where  the 


manager  has  complete  control  of  both  computer  and  soft¬ 
ware.  The  paper  will  outline  the  ways  a  computer  can  as¬ 
sist  the  manager  in  everyday  duties  rather  than  mandate 
what  should  be  done  and  how  to  do  it.  This  thesis  will 
also  illustrate  how  this  approach  can  be  cost  effective 
when  compared  to  using  the  large  systems  only,  and  in 
terms  of  taking  advantage  of  the  expertise  which  typically 
exists  within  the  technical  setting  of  the  clinical  labo¬ 
ratory. 

What  the  Laboratory  Manager  Needs 

The  head  of  a  military  clinical  laboratory  is  seldom 
able  to  interrupt  his  administrative  or  consultative  du¬ 
ties  to  work  side-by-side  with  the  technicians.  Never¬ 
theless,  the  manager  is  ultimately  responsible  for  each 
result  reported  by  the  laboratory  staff.  The  Joint  Com¬ 
mission  on  Accreditation  of  Hospitals  (JCAH)  requires  that 
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the  laboratory  director1 2 3  or  a  designee  review  these  re¬ 
sults  at  least  daily,  and  preferably  prior  to  reporting 
them  [22,  p.  149].  Since  this  duty  is  often  delegated  to 
subordinates,  the  supervisor  must  be  confident  of  the 
quality  control  procedures  in  place  in  the  laboratory. 
Most  of  these  procedures  are  local  implementations  of 
those  dictated  by 

(1)  the  College  of  American  Pathologists  (CAP), 

(2)  the  JCAH, 

(3)  the  Department  of  Defense  (DoD), 

(4)  the  Air  Force, 

(5)  the  Major  Command  (MAJCOM) ,  and/or 

(6)  the  hospital. 

Formal  application  of  a  quality  control  procedure  is  only 
required  if  it  is  applicable  to  the  individual  laboratory 
(22,  pp.  ix,  141-161].  Also,  most  of  the  DoD  and  Air 
Force  regulations  are  based  on  the  CAP.  In  any  case,  the 
methods  of  quality  control  employed  by  a  given  laboratory 
are  typically  selected  to  be  most  efficient  for  that  par¬ 
ticular  laboratory.  Whatever  the  methods,  a  quality-con¬ 
trol  information  system  should  be  flexible  enough  to  sat- 


2The  Laboratory  Director  is  defined  by  the  JCAH  to  be 
one  of  the  following,  in  order  of  preference: 

(1)  A  pathologist  on  the  medical  staff, 

(2)  A  nonpathologist  physician  on  the  medical 
staff  who  is  knowledgeable  in  laboratory  proce¬ 
dures,  or 

(3)  A  doctoral  scientist  with  his  degree  in  a 
laboratory  discipline  (22,  pp.  141-142]. 
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isfy  both  the  manager  and  those  who  evaluate  the  perfor¬ 
mance  of  the  laboratory.  Also#  it  should  be  simple  and 
consistent  enough  to  have  its  data  supplied  by  the  techni¬ 
cians. 

In  addition  to  technical  quality  control#  the  mili¬ 
tary  laboratory  manager  should  have  a  tool  available  to 
assist  in  nonmedical  supervisory  duties.  These  duties 
roughly  include  the  automated  assistance  expected  by  any 
small  business,  with  the  possible  exception  of  accounts 
receivable.  Budgeting#  correspondence#  personnel  manage¬ 
ment.  workload  forecasting#  periodic  reports  and  re¬ 
quirements,  inventory,  modeling^#  and  extra  unrelated  as¬ 
signed  duties  are  all  subject  to  improvement  through  the 
use  of  more  efficient  methods. 

Finally#  automation  of  some  of  the  purely  profes¬ 
sional  work  of  the  laboratory  manager  may  be  useful.  If 
the  laboratory  is  involved  with  active  research#  the  busi¬ 
ness  abilities  cited  above  would  likely  prove  to  be  very 
valuable  when  used  with  newly  developed  databases t  the 
organization  of  standard  references  could  also  be  added  to 


^Modeling  in  the  computer  sense  is  a  method  by  which 
a  computer  is  programmed  to  mimic  the  activity  of  some 
task#  situation#  or  sequence  of  events,  allowing  the  oper¬ 
ator  to  view  the  likely  outcome  without  actually  undertak¬ 
ing  the  task. 


the  list.  Computer-aided  diagnosis  is  another  possibil¬ 
ity,  both  as  a  tool  for  the  laboratory  and  as  a  resource 
for  physicians  who  request  a  consult. 


History  of  Laboratory  Computin 


It  is  not  difficult  to  picture  the  enthusiasm  with 
which  laboratorians  embraced  the  concept  of  laboratory  au¬ 
tomation.  They  are,  after  all,  known  properly  as  Medical 
Technologists4.  As  the  volume  of  test  requests  increased, 
the  thought  of  replacing  the  drudgery  of  manually  perform¬ 
ing  sensitive,  complicated,  and  labor-intensive  procedures 
on  seemingly  endless  streams  of  specimens  with  instrumen¬ 
tation  became  increasingly  attractive.  With  this  new  ca¬ 
pability,  not  only  could  the  work  be  more  enjoyable,  but 
the  results  would  be  more  consistent)  variations  between 
technologists  and  inherent  human  imprecision  would  be 
eliminated.  Many  such  instruments  have  been  developed  and 


4There  is  a  significant  difference  between  a  Medical 
Technologist  and  a  Medical  Laboratory  Technician,  the  for¬ 
mer  requiring  a  degree  from  an  approved  School  of  Medical 
Technology.  In  the  Air  Force  setting,  laboratory  officers 
(managers)  are  Medical  Technologists.  Technicians  must 
complete  a  year-long,  two-phase  training  program  before 
working  in  the  laboratory.  This  training  is  approximately 
equivalent  to  that  of  a  civilian  Medical  Laboratory  Tech¬ 
nician.  In  this  paper,  a  "technologist"  generally  refers 
to  a  member  of  either  group. 
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improved  upon)  those  which  did  not  meet  these  lofty  expec¬ 
tations  were  not  accepted.  Until  the  advent  of  the  micro¬ 
processor,  an  instrument  could  best  be  described  as  just 
another  piece  of  expensive  equipment  which  the  technolo¬ 
gist  wielded.  Instruments  would  not  operate  unattended  or 
make  decisions  based  on  their  analyses.  But  automation 
did  facilitate  much  higher  throughput  for  the  laboratory, 
and  eventually  the  relative  overall  cost  per  procedure 
started  to  come  down. 

The  idea  of  placing  a  computer  in  charge  of  the  in¬ 
strument  was  met  with  somewhat  less  enthusiasm  [45,  p. 
149].  Would  Medical  Technologists  become  nothing  more 
than  phlebotomists  and  specimen  pushers?  Could  they,  or 
the  physicians,  trust  the  results?  And  what  would  happen 
if  the  machine  broke  down?  After  all,  the  heart  of  the 
system  was  to  be  a  computer,  that  ethereal  monster  whose 
workings  were  to  be  understood  by  only  the  mightiest  of 
minds.  But  the  frontier  was  open  and  several  established 
instruments  started  to  incorporate  microprocessor  control 
into  their  operations.  These  instruments  had  all  the 
weaknesses  of  the  early  computers — they  were  costly  and 
proved  too  unreliable  for  medical  equipment.  Also,  they 
were  not  powerful  enough  to  offer  any  great  advantage  over 
previous  instruments. 
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By  the  early  1970s,  computers  had  outgrown  some  of 
their  weaknesses  and  were  again  considered  for  inclusion 
in  medical  laboratory  instrumentation.  In  the  early 
1960s,  the  AutoAnalyzer®  [36,  p.  157]  (figures  1.1  and 
1.2)  and  the  Coulter  Counter6  [40,  p.  192]  (figures  1.3 
and  1.4)  established  industry  standards  in  automated  chem¬ 
istry  and  hematology  analyses,  respectively.  The  high 
volumes  of  work  these  and  similar  instruments  could  handle 
made  systems  to  sort  the  data  become  attractive.  Informa¬ 
tion  systems,  such  as  MEOLAB,  MEDITECH,  CHC,  and  LAB FORCE, 
were  already  available  for  laboratories  [7,  p.  48].  These 
could  generally  handle  much  of  the  paperwork  associated 
with  the  specimens,  including  workload  lists,  quality  con¬ 
trol  data,  patient  demographics,  and  reports,  but  they 
were  primarily  intended  to  serve  the  entire  hospital  with 
laboratory  order  entry  and  retrieval. 

In  the  19808,  it  is  rare  to  find  a  laboratory  of  any 
size  which  has  no  computerized  instrumentation.  The  over¬ 
all  cos t  of  medical  care  has  had  a  profound  effect  on  the 
laboratory.  In  a  hospital,  the  laboratory  is  typically 
one  of  the  top  revenue-producing  departments  and  its  gen- 

^Technicon  Corporation,  Tarrytown,  New  York. 

^Coulter  Electronics,  Inc.,  Hialeah,  Florida. 


Pigure  1.1.  An  early  SMA  12/60  AutoAnalyzer  CIS,  p.  153] 


*  computerized  »C  IX  AutoAnalyzer 


Figure  1*2 


Figure  1.4.  A  computerized  Model  S-Plus  IV  Coulter 
Counter  [9,  p.  xii] . 


erous  use  by  physicians  has  always  been  encouraged.  The 
luxury  of  abunuant  laboratory  data  concerning  a  patient 
quickly  became  the  norm.  The  advent  of  diagnosis-related 
groups7  (DRGs) ,  however,  has  threatened  this  bastion  of 
defensive  medicine  unless  the  cost  per  test  can  be  further 
reduced  [3,  p.  31].  Instruments  today  are  designed  for 
high-volume,  low-attention  work.  The  larger  ones  often 
contain  their  own  information  system  to  monitor  and  direct 
their  operations  on-line.  They  can  generate  and  maintain 
quality  control  data  and  verify  each  test  against  this 
data,  perform  periodic  calibrations  automatically,  detect 
and  diagnose  failures  and  direct  the  operator  in  the  re¬ 
pair,  and  even  communicate  with  similar  systems  elsewhere 
to  maintain  uniformity.  Most  will  interface  readily  with 
other  on-site  computer  systems.  This  "walk-away"  capabil¬ 
ity  is  now  very  much  in  demand,  allowing  technologists  to 
perform  multiple  simultaneous  tasks.  It  is  clear  that 
computer  knowledge  will  soon  be  a  requirement  for  graduat¬ 
ing  medical  technologists »  indeed,  many  continuing  medical 
education  programs  include  computer  seminars  [39,  p.  885], 

7Diagnosis-related  groups  are  means  by  which  Medicare 
reimbursements  to  a  hospital  are  based  on  expenses  typi¬ 
cally  incurred  for  a  patient  with  a  given  diagnosis. 
Costs  beyond  this  standard  for  a  given  patient  must  often 
be  absorbed  by  the  hospital. 


and  schools  of  medical  technology  are  requiring  computer- 
oriented  study  with  increasing  regularity  [43,  p.  663]. 


Overview  of  Following  Chapters 


Throughout  this  paper,  particular  attention  is  fo¬ 
cussed  on  typical  small  Air  Force  hospital  and  clinic  lab¬ 
oratories.  These  laboratories  employ  about  five  to  twenty 
persons.  The  larger  ones  are  usually  headed  by  an  officer 
holding  the  credentials  of  a  Medical  Technologist,  the 
rest  by  relatively  senior  enlisted  personnel.  Despite  the 
differences  in  size  and  leadership,  all  of  them  share  many 
of  the  same  management  problems.  Most  of  these  problems 
are  common  to  all  departments  of  clinical  pathology,  but 
some  are  unique  to  the  Air  Force. 

Chapter  Two  discusses  some  of  the  systems  currently 
used  to  perform  the  routine  information-related  tasks  re¬ 
quired  of  the  laboratory.  The  strengths  and  weaknesses  of 
laboratory  systems  in  the  DoD  are  explored,  along  with  the 
management  needs  they  support.  For  those  systems  still 
not  fully  implemented,  some  predictive  usefulness  will  be 
involved. 

Chapter  Three  is  involved  with  the  other  tasks  which 
would  be  very  useful  to  the  laboratory  if  they  were  sup- 
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ported  by  the  information  system.  Some  of  these  tasks  are 
obvious,  but  they  are  seldom,  if  ever,  integrated  into  the 
systems  discussed  in  Chapter  Two. 

Chapter  Four  is  concerned  with  the  systems  analysis 
of  the  proposed  stand-alone  system.  A  typical  laboratory 
data  flow  description  is  presented  along  with  the  en¬ 
vironmental  factors,  both  physical  and  work  related,  which 
must  be  considered.  Some  of  the  hardware  and  software 
currently  available  which  will  support  this  analysis  is 
discussed  in  this  chapter. 

Justification  for  various  configurations  supporting 
the  established  requirements  is  presented  in  Chapter  Five. 
Hardware  and  software  availability,  cost,  and  implementa¬ 
tion  time  are  explored.  These  attributes  are  compared  to 
those  related  to  systems  currently  under  development.  The 
utility  of  the  stand-alone  system  by  the  local  laboratory 
management  is  particularly  emphasized. 

Chapter  Six  discusses  the  physical  implementation  of 
the  proposed  system  and  its  impact  on  the  laboratory.  It 
covers  acquiring  the  system  under  existing  governmental 
standards,  testing  the  hardware  and  software,  and  the 
training  involved  with  the  conversion  from  the  present 
system.  Maintenance  and  reliability  are  addressed  here, 
also. 


** 


17 


Chapter  Seven  comprises  the  author's  conclusions  and 
recommendations  for  further  study. 


CHAPTER  II 


CURRENT  SYSTEMS 


Manual  Methods 


The  standard  method  for  technical  and  managerial  du¬ 
ties  has  always  been  to  document  these  performances  by 
hand.  A  writing  instrument,  paper,  a  correction  method, 
and  sometimes  a  typewriter  were  the  basic  pieces  of  equip¬ 
ment.  The  local  laboratory  could,  and  generally  did.  de¬ 
velop  its  own  conventions,  such  as  using  red  ink  for  en¬ 
tering  stat1  requests  on  the  work  logs.  Regardless  of  the 
method  employed,  there  can  be  no  argument  that  records  of 
virtually  every  activity  of  the  laboratory  must  be  created 
and  maintained.  Every  accrediting  agency,  as  well  as  com¬ 
mon  sense  and  good  defensive  medicine,  makes  this  abso- 


^■Stat  is  accepted  medical  jargon  designating  those 
actions  which  should  be  given  priority  over  other  activi¬ 
ties  because  of  medical  urgency.  Technically,  it  should 
be  written  stat . .  an  abbreviation  for  the  Latin  statim. 
meaning  "immediately. "  Although  its  use  is  often  abused 
as  a  convenience,  it  is  reserved  for  those  cases  where  de¬ 
lay  would  likely  result  in  loss  of  life.  limb,  or  cause 
undue  suffering.  The  jargon  permits  its  use  as  an  adverb 
("Do  it  stat I"),  as  an  adjective  ("a  stat  glucose"),  or  as 
a  noun  ("Has  the  stat  arrived  yet?"). 


lutely  clear.  In  addition,  many  of  these  records*  such  as 
procedure  manuals  and  daily  work  logs*  must  be  created  in 
a  relatively  standard  way  to  make  it  easy  to  consult  them 
when  necessary.  Others,  such  as  Airman  Performance  Re¬ 
ports  (APRs)  and  Officer  Effectiveness  Reports  (OERs)  have 
exacting  standards  dictated  by  appropriate  rules  or  regu¬ 
lations  [12.  p.  12].  The  result  of  all  this  is  a  separa¬ 
tion  of  the  actual  performance  of  the  testing  procedures 
from  its  associated  documentation.  Nevertheless,  both 
must  be  completed,  together  with  the  required  certifica¬ 
tion,  before  the  job  can  be  considered  finished.  Conse¬ 
quently,  much  of  the  paperwork  is  such  that  it  cannot  be 
left  to  be  done  as  a  batch  job. 

The  actual  pencil -and-paper  creation  of  this  documen¬ 
tation  typically  takes  many  forms.  Most  formal  correspon¬ 
dence  is  typewritten;  orders,  notes,  and  record  entries 
are  usually  handwritten  and  may  later  be  transcribed  by  a 
typing  pool.  Some  laboratories  may  have  the  luxury  of 
dictation  support,  but  this  is  rare  and  virtually  nonexis¬ 
tent  in  the  small  laboratories.  Procedure  manuals  must  be 
typed,  but  must  also  be  reviewed  at  least  annually  by  the 
department  head;  his  corrections  and  updates  are  pen-and- 
ink,  and  every  procedure  must  bear  his  initials  and  the 
date  of  review.  Work  logs  are  standard  forms  onto  which 


patient  demographics  and  results  are  transcribed;  some  au¬ 
tomated  instruments  will  generate  these  forms  automati¬ 
cally  after  the  information  is  typed  into  the  integral 
console  on  the  instrument.  These  logs  eventually  become 
the  archival  records.  They  and  the  laboratory's  copy  of 
the  completed  request  form  typically  represent  the  only 
documentation  held  by  the  laboratory  for  a  given  test. 
Copies  are  provided  for  the  patients'  charts  and  for  the 
requesting  physician,  but  these  are  distributed  and  main¬ 
tained  outside  the  laboratory.  Retrieval  of  this  archived 
information  involves  a  manual  chronological  file  search 
using  the  patient  and  the  requested  test(s)  as  a  concate¬ 
nated  key.  The  request  for  such  a  search  must  be  person- 
to-person.  either  in  writing  or  by  voice.  Quality  control 
data  contained  on  these  logs  must  be  transcribed  by  hand 
to  separate  computational  logs  or  to  the  standard  forms 
provided  by  third-party  vendors.  Typing  is  usually  re¬ 
quired  to  complete  the  standard  forms  of  recurring  re¬ 
ports.  Methods  for  managing  activities  such  as  inventory, 
shipping  and  receiving,  cost  center  data,  and  personnel 
must  also  be  developed  and  records  maintained  in  accor¬ 
dance  with  appropriate  regulations  and  local  convenience. 

Each  of  the  documentation  activities  mentioned  above 
will  result  in  its  own  file,  the  maintenance  of  which  is 


itself  subject  to  control.  Storage  protocols*  physical 
security*  access  control*  and  the  privacy  act  must  all  be 
considered  and  are  mandated  to  some  extent  by  regulation. 
(Fortunately*  laboratories  do  not  have  a  need  to  maintain 
classified  documents  for  any  length  of  time.)  Each  of 
these  files  provides  the  legal  protection  and  required 
documentation  for  the  activities  of  the  laboratory*  but 
are  accessible  only  through  a  physical  search.  They  are 
also  subject  to  common  problems  associated  with  such  a 
file*  such  as  illegibility*  transcription  errors*  mis¬ 
placement*  lack  of  storage  space*  and  accidental  damage  or 
destruction  due  to  frequent  or  aggressive  access.  Elimi¬ 
nating  these  problems  and  the  time  and  effort  required  to 
generate  and  search  the  files  are  the  major  attractions  of 
an  automated  system. 


Automated  Methods 


Automated  laboratory  information  systems  have  re¬ 
ceived  considerable  attention  by  instrument  manufacturers 
for  some  time.  At  first*  the  systems  were  designed  to 
work  with  a  specific  instrument  supplied  or  supported  by 
the  company.  As  laboratories  acquired  various  instru¬ 


ments*  each  with  its  own  information  management  system* 


the  laboratory  was  forced  to  alter  or  develop  record-keep¬ 
ing  procedures  to  conform  with  the  information  produced  by 
these  instruments.  Although  the  types  of  information  were 
reasonably  standard  due  to  written  guidelines  and  tradi¬ 
tion.  the  means  by  which  the  information  was  presented 
varied  considerably.  These  variations  made  comparisons 
between  the  different  instruments  and  operators  difficult. 

Because  of  the  relatively  standard  data  generation 
and  information  requirements  of  a  typical  laboratory,  de¬ 
veloping  a  system  to  integrate  the  various  forms  of  data 
into  useful  information  was  not  especially  difficult. 
However,  gathering  and  inputting  the  data  presented  some 
challenges.  Manually  entering  the  outputs  of  the  various 
instruments  into  the  integrated  system  was  a  task  to  be 
avoided  unless  the  benefits  derived  from  the  system  were 
determined  to  justify  this  duplication  of  effort.  Col¬ 
lecting  the  data  directly  from  the  instrument  (on-line) 
was  the  obvious  solution,  and  as  soon  as  the  instruments 
were  designed  to  interface  with  external  systems,  this 
level  of  integration  became  possible.  The  emergence  of 
somewhat  standard  data  transfer  protocols,  such  as  RS-232. 
made  interfacing  much  easier,  although  hardware  and/or 
software  interfaces  are  still  typically  necessary.  The 
host  system  must  still  accept  manual  input,  for  it  is  a 


rare  laboratory  which  has  no  manual  testing  procedures. 
Also*  operator  intervention  will  usually  be  required  when 
unusual  circumstances  arise*  such  as  error  recovery  or 
special  treatment  of  specific  samples. 

Centralized  laboratory  management  systems  are  still 
designed  to  handle  laboratory  information  according  to  the 
traditional  methods  with  which  nearly  all  laboratorians 
are  familiar.  The  end  product  still  is  usually  a  log 
which  the  machine  generates  and  will  be  filed  in  the  usual 
way.  The  difference  is  that  automated  systems  can  also 
generate  machine-readable  archives  which  are  quickly 
searched,  eliminating  the  need  for  a  paper  search.  Of 
course,  memory  constraints  require  that  old  archive  en¬ 
tries  be  removed  from  the  automated  system  after  some  es¬ 
tablished  period  of  time  and  stored  in  the  conventional 
manner.  These  logs  and  archives  can  be  composites  of  all 
the  departments  of  the  laboratory*  minimizing  the  duplica¬ 
tion  of  patient  demographics  and  making  it  possible  to 
correlate  all  results  derived  throughout  the  laboratory 
for  a  given  patient.  Comparisons  of  methods*  instruments* 
and  technologists  are  much  easier  and  more  meaningful  when 
the  data  are  uniformly  formatted.  Therefore,  maintaining 
current  management  methods  and  standard  documentation  sys¬ 
tems  is  the  goal  of  both  manual  and  automated  information 
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evolved  is  beyond  the  scope  of  this  paper*  but  the  reader 
is  referred  to  Packman  [31]  for  a  thorough  discussion. 
The  intent  was  to  develop  a  complete  medical  information 
system  for  general  use  throughout  the  DoD,  with  each  MTF 
accessing  a  common  database  which  would  contain  the  medi- 
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cal  records  of  each  patient.  This  would  make  any  civilian 
system  currently  in  use  at  a  military  laboratory  immedi¬ 
ately  inadequate.  As  a  result  of  this  interest,  four  lab¬ 
oratory  systems  have  been  researched,  two  of  which  are 
currently  in  place.  These  are  the  Regenstrief  Clinical 
Laboratory  System  (RCLS),  TRILAB,  the  Veterans  Adminis¬ 
tration  Decentralized  Hospital  Computer  Program  (VADHCP) , 
and  the  Composite  Health  Care  System  (CHCS). 

RCLS 


The  RCLS  concentrates  on  maintaining  a  maximum  amount 
of  patient  data  in  a  minimum  of  space,  allowing  data  to 
remain  available  for  a  maximum  length  of  time.  This  is 
accomplished  by  using  "a  true  database  management  system” 
and  packing  data  for  storage.  Coding  permits  almost  any 
data,  including  common  text  responses,  to  be  stored  in 
only  16  bits,  and  ”only  the  most  clinically  relevant  in¬ 
formation”  is  stored  on-line.  The  remainder  is  stored  us¬ 
ing  other  archiving  methods.  Redundancy  is  eliminated  by 
merging,  and  the  result  is  ”over  five  years  of  laboratory 
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work  for  over  30, 000  patients  using  under  200*000  bytes  of 
storage.  .  .  "2  [26,  p.  2541. 

The  system  also  emphasizes  making  the  system  easily 
accessible  by  the  physician  and  information  is  formatted 
according  to  his  needs.  He  can  use  the  database  directly 
with  a  query  language  called  CARE,  which  is  easy  to  learn 
and  also  incorporates  "ideal  rules  of  care"  which  are  used 
to  flag  questionable  or  unnecessary  requests  as  well  as  to 
avoid  overlooking  important  information.  Screens  have 
been  designed  to  be  easily  understood  by  unskilled  users* 
both  for  input  and  for  retrieval. 

The  system  supports  management  uses  by  "modifying  the 
system  without  programming."  Standard  database  commands 
are  consolidated  with  given  modules  to  produce  a  command 
language.  This  can  be  used  to  generate  ad  hoc  reports  or 
to  maintain  the  database.  Workload  lists,  billing*  and 
quality  control  statistics  are  also  produced  [26*  pp.  255- 
256]. 

The  RCLS  was  installed  in  1975  at  Wishard  Memorial 
Hospital  in  Indianapolis*  Indiana*  and  at  Wilford  Hall 

2This  statement  implies  that  a  typical  patient's 
demographics  and  five-year  laboratory  history  can  be  con¬ 
tained  in  less  than  7  bytes  (54  bits).  This  is  obviously 
not  really  possible.  The  statement  probably  refers  to  a 
200,000-byte  memory-resident  directory  to  the  much  larger 
archives  stored  on  large  disk  packs. 


Medical  Center,  San  Antonio,  Texas,  in  1981.  Currently, 
Wilford  Hall  i*»  the  only  Air  Force  facility  running  it. 
It  is  designed  to  run  on  VAX  computers  from  Digital  Equip¬ 
ment  Corporation  (DEC)  and  is  written  in  compiled  VAX 
BASIC  [26,  p.  256]. 


TRILAB 


TRILAB-3  is  related  to  the  MEDITECH  system  already 
noted  in  Chapter  One.  The  first  Air  Force  installation 
was  at  Wright -Pat ter son  AFB,  Ohio,  in  1981.  TRILAB  cur¬ 
rently  is  also  in  operation  at  Andrews  AFB,  Maryland; 
Sheppard  AFB,  Texas;  Scott  AFB,  Illinois;  and  seven  other 
non-Air  Force  DoD  facilities.  No  other  Air  Force  instal¬ 
lations  are  scheduled  to  receive  TRILAB,  although  smaller 
laboratories  can  be  indirectly  served  by  it.  Sheppard 
AFB,  for  instance,  serves  as  a  reference  laboratory  for 
the  laboratory  at  Altus  AFB.  Through  a  modem  link  and 
voice  recognition  equipment,  the  Altus  staff  can  monitor 
and  receive  the  results  for  the  samples  sent  to  Sheppard. 

TRILAB  is  an  integrated  laboratory  management  system 
which  provides  most  of  the  management  tools  available  with 

^Medical  Information  Technology,  Inc., 
Massachusetts. 


Cambridge, 


other  packages,  such  as  the  RCLS.  It  is  written  in  the 
MUMPS  language^,  which  was  originally  designed  to  allow 
the  program  to  be  easily  changed  to  meet  special  needs, 
but  TRILAB  removes  this  option.  It  also  forces  the  labo¬ 
ratory  to  buy  instrument  interfaces  from  the  vendor,  even 
if  no  hardware  is  involved  [32,  p.  1J.  A  comparison  of 
TRILAB  and  the  RCLS  [32,  p.  2]  notes  that  in  TRILAB  "CAP 
workload  procedures  is  [sic]  probably  the  best  available" 
and  the  "method  of  handling  optional  tests  in  batter¬ 
ies^  ...  is  exceptionally  good."  However,  although  most 
of  the  desired  laboratory  information  handling  is  sup¬ 
ported,  there  exist  some  aspects  where  the  support  is  less 
than  should  be  expected®  [32,  pp.  1-2]. 

(1)  "System  evolution"  has  not  progressed  as 
fast  as  a  typical  commercial  product  should 
have. 

(2)  Documentation  is  poor. 

(3)  The  heirarchical ,  menu-driven  command 
structure  can  be  cumbersome. 


*MUMPS  is  an  acronym  for  the  computer  operating  sys¬ 
tem  and  language  known  as  the  Massachusetts  General  Hospi¬ 
tal  Utility  Mul ti -Programming  System. 

5A  battery  is  a  group  of  individual,  related  tests 
which  can  be  ordered  as  if  they  were  a  single  test.  For 
instance,  a  liver  function  test  (LFT)  may  consist  of  dis¬ 
crete  analyses  for  several  different  liver  enzymes. 

®Since  this  list  is  from  a  comparison  of  TRILAB  and 
the  RCLS,  it  can  be  assumed  that  the  RCLS  does  not  suffer 
from  the  listed  weaknesses.  However,  this  does  not  imply 
that  the  RCLS  is  exceptionally  strong  in  these  areas. 
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(4)  Reports  do  not  spool. 

(5)  The  microbiology  subsystem  is  separate  from 
the  main  system  and  does  not  operate  in  a 
completely  parallel  way. 

(6)  Only  a  single  name  for  a  test  is  allowed, 
e.g. ,  SGOT,  GOT,  OT,  and  AST7  would  all  be 
considered  separate  tests. 

(7)  Multiple-file  structure  reduces  the  flexi¬ 
bility  of  queries  relating  to  patients. 


VADHCP 


The  Veterans  Administration  Decentralized  Hospital 
Computer  System  began  as  the  work  of  a  group  of  loosely- 
organized  VA  programmers  who  saw  the  need  for  hospital  in¬ 
formation  systems.  Their  work  progressed  until  formal 
recognition  was  granted  when  "a  VA  Executive  Order  estab¬ 
lished  the  Medical  Information  Resources  Management  Office 
(MIRMO)  and  the  Decentralized  Hospital  Computer  Program 
(DHCP)"  (28,  p.  1],  Many  programmers  participated  in  the 
development  of  the  various  modules,  and  there  eventually 
emerged  two  factions  possessing  "philosophical  differ¬ 
ences."  One  group  favored  "a  loosely  controled  [sic]  pro- 


7GOT  is  an  acronym  for  glutamate  oxalacetate  transam¬ 
inase,  a  liver  enzyme.  The  prefix  S  indicates  that  the 
sample  is  blood  serum,  by  far  the  most  commonly-used 
source,  and  is  frequently  omitted.  OT  is  sometimes  used 
when  there  is  no  ambiguity  possible.  AST  stands  for  as¬ 
partate  aminotransferase,  another  descriptive  name  for  the 
same  enzyme.  The  interested  reader  is  referred  to  Tietz 
[41,  pp.  672-682]. 


cess  allowing  great  latitude  in  local  hospital  design  of 
systems,  the  DHCP"  [28,  p.  1].  The  other  advocated  "a 
more  centralized  approach  similar  to  that  of  the  TRXMIS 
program — commercial  procurement  of  vendor  developed  hospi¬ 
tal  information  systems"  [28,  p.  2].  This  was  eventually 
resolved  by  legislation  in  December  of  1982  mandating  the 
implementation  of  the  DHCP  approach  [28,  p.  1].  When  the 
TRIMIS  Program  Office  (TPO)  announced  in  May  of  1984  that 
the  DoD  would  concentrate  its  efforts  on  the  CHCS  (a  cen¬ 
tralized  system)  only,  the  Chairman  of  the  House  Veterans 
Affairs  Committee,  G,  V,  Montgomery,  advocated  the  use  of 
the  DHCP  as  being  more  cost  effective.  His  increasing 
criticism  of  the  TRIMIS  program  eventually  resulted  in  the 
hiring  of  the  MITRE  Corporation  to  assess  "the  feasibility 
of  using  the  VA  DHCP  in  the  TRIMIS  program"  and  in  permis¬ 
sion  and  funding  to  test  the  DHCP  at  March  Air  Force  Base 
by  the  Arthur  D.  Little  Corporation  [28,  pp.  2-3]. 

Both  reports  showed  deficiencies.  The  MITRE  report, 
released  in  January  of  1985,  concluded  that  "there  was  a 
30  percent  match  with  the  CHCS  functional  requirements 
.  .  .  and  a  65  percent  match  with  the  technical  require¬ 
ments.  .  ."  [28,  p.  3].  The  Little  report,  issued  in  May 
of  1985,  indicated  that  "users  were  satisfied"  and 
"functionality  was  adequate"  but  suggested  that  appoint- 


ment  scheduling  was  "time  consuming"  and  "cumbersome"  and 
that  its  use  ".  .  .  in  a  large  clinic  with  many  providers 
and  volatile  provider  schedules  may  be  problematic"  [30, 
p.  1],  Representative  Montgomery  was  critical  of  both  re¬ 
ports  and  attempted  to  halt  the  CHCS.  The  result  was  an 
amendment  in  August  of  1985  to  the  Fiscal  Year  (FY)  1985 
Defense  Authorization  Act  which  mandated  [30,  pp.  1-2] : 

Expanded  test  at  March  and  one  other  DoD  hospi¬ 
tal  of  significantly  larger  size; 

Test  to  commence  not  later  than  1  March  1986  for 
six  month  period; 

Must  include  all  currently  available  software 
packages  of  the  DHCP; 

Must  assess  the  feasibility  and  cost  advantage 
that  would  accrue  from  the  short  term  implemen¬ 
tation  of  the  DHCP  in  lieu  of  the  cost  of  the 
longer  term  "higher  risk"  procurement  of  the 
CHCS;  and 

TPO  cannot  make  final  contractor  selection  for 
the  CHCS  until  the  Comptroller  General  files  a 
final  report  on  the  evaluation  and  the  Congress 
makes  its  final  determination  of  which  of  the 
two  systems  will  be  used. 

It  must  be  noted  that  the  laboratory  module  was  not  a  part 
of  the  system  described  by  the  MITRE  and  Little  reports, 
but  the  module  is  included  in  the  current  testing  at 
March,  as  directed.  The  length  of  the  testing  time  was 
recently  extended  to  December  of  1986. 


The  actual  laboratory  functions  of  the  VADHCP  are 
similar  in  purpose  to  the  other  systems  previously  dis¬ 


cussed  (23,  pp.  3-4].  Like  TRILAB,  it  is  written  in 
MUMPS,  but  the  inaccessibility  of  the  TRILAB  code  has  been 
largely  avoided.  The  VADHCP  is  also  very  similar  to  TRI¬ 
LAB  in  its  design,  operation,  and  use.  Interestingly,  it 
is  likely  to  become  more  like  TRILAB  as  testing  continues 
and  modules  are  modified  by  individuals  familiar  with  TRI- 
LAB's  operation.  At  the  same  time,  this  familiarity  may 
avoid  some  of  the  perceived  weaknesses  of  TRILAB. 


CHCS 


The  CHCS  represents  the  single  information  system  de¬ 
signed  for  use  by  all  Air  Force  medical  treatment  facili¬ 
ties.  The  CHCS  is  not  limited  to  laboratory  use,  but  is 
intended  to  be  a  total  health  care  information  system. 
However,  the  laboratory  module  can  be  discussed  individu¬ 
ally  and  the  functional  descriptions  (FDs)  for  this  single 
module  have  been  formulated  (42,  pp.  3-1  -  3-41].  This 
module  is  part  of  phase  two  of  a  three-phase  installation, 
the  first  of  which  is  scheduled  to  take  place  at  Sheppard 
AFB,  Texas,  by  1  September  1987.  Phase  two  is  scheduled 
to  commence  at  Sheppard  on  1  March  1988.  At  the  time  of 
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this  writing*  bids  are  still  being  solicited  for  develop¬ 
ment  of  the  system.  The  following  discussion*  therefore* 
is  based  on  the  functional  descriptions  alone}  no  evalua¬ 
tion  can  be  made  about  whether  or  how  well  the  system  sat¬ 
isfies  the  FDs. 

Since  the  CHCS  is  intended  to  eventually  be  part  of 
every  laboratory*  it  is  important  to  note  the  objectives 
of  the  program.  The  CHCS  will  likely  be  the  integrated 
system  which  will  be  augmented  by  the  stand-alone  system 
this  paper  recommends.  Figures  2.1  and  2.2  list  these  ob¬ 
jectives.  The  objectives  appear  to  address  approximately 
the  same  activities  as  most  of  the  predecessors  of  the 
CHCS.  Particular  emphasis  is  placed  on  minimizing  paper 
handling  in  the  laboratory*  thereby  eliminating  many  human 
documentation  errors.  Experienced  laboratory  managers 
will  recognize  that  some  thought  was  given  to  management 
of  tangentially  related  duties*  since  support  for  the  Drug 
Testing  Program**  is  to  be  provided. 


®The  Air  Force  Drug  Testing  Program  involves  collec¬ 
tion  and  shipment  of  urine  samples  from  Air  Force  members 
under  strictly  defined  conditions.  Since  collection  and 
shipment  of  body  fluids  logically  falls  to  the  laboratory* 
the  laboratory  is  tasked  with  much  of  the  administration 
of  the  program.  The  nature  of  this  program  tends  to  make 
the  activity  more  a  legal  responsibility  than  a  medical 
one*  and  the  required  management  practices  associated  with 
the  program  do  not  conform  easily  with  established  labora¬ 
tory  protocols.  | 

i 
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a.  Share  core  functions  among  all  authorized  users 

in  the  MTF  work  centers. 

b.  Standardize  functional  communications  throughout 

the  MTF. 

c.  Provide  a  flexible  and  powerful  framework  for 

the  growth,  development,  and  evaluation  of 
functions  and  workload. 

d.  Provide  high  system  reliability  with  graceful 

failure  of  functions. 

e.  Share  patient  administrative  and  clinical  data 

with  all  authorized  users  within  the  MTF. 

f.  Integrate  the  functional  medical  information  and 

requirements  of  various  work  centers  to  ensure 
the  capabilities  to  collect,  store,  modify,  re¬ 
trieve,  and  report  MTF  level  patient  and  man¬ 
agement  transaction  data. 

g.  Limit  redundant  collection  of  data  to  the  extent 

required  by  the  MTF. 

h.  Provide  for  standardized  order  entry  and  results 

reporting  for  all  medical  information  within 
the  system. 

i.  Protect  the  security  and  privacy  of  patient  and 

staff  information. 

j.  Collect  administrative  data  as  a  by-product  of 

health  care  delivery  for  purposes  such  as  UCA, 
budgeting,  QA  [Quality  Assurance],  etc. 

k.  Improve  the  quality  of  patient  care  as  a  result 

of  more  thorough  collection,  better  or¬ 
ganization,  and  more  timely  and  accurate  avail¬ 
ability  of  patient  information. 

l.  Reduce  the  time  to  transmit  information  on  ad¬ 

missions,  dispositions,  transfers,  patient  sta¬ 
tus,  patient  care  orders,  and  diagnostic  re¬ 
sults  within  the  MTF. 

m.  Interface  with  non-CHCS  systems  which  share  or 

require  information  from  the  CHCS  work  centers. 

n.  Provide  interface  to  non-CHCS  systems  such  as 

DEERS  [Defense  Enrollment  Eligibility  Reporting 
System],  Food,  Logistics,  without  active  in¬ 
volvement  of  MTF  staff  in  routine  interactions. 

o.  Prevent  the  loss  or  degradation  of  functional 

medical  information  through  the  provision  of 
standard  failure  contingency  and  security  ca¬ 
pabilities. 


Figure  2.1.  CHCS  objectives  [42,  p.  2-2]. 


Provide  a  totally  integrated  data  management 
capability  that  supports  Clinical  Pathol¬ 
ogy*  Anatomical  Pathology,  and  Blood  Bank 
services. 

Reduce  transcription  and  transcription  er¬ 
rors. 

Provide  for  early  accountability  for  labora¬ 
tory  orders. 

Reduce  the  amount  of  clerical  tasks  per¬ 
formed  by  technicians  by  automatically 
preparing  work  documents,  labels  and  other 
products. 

Reduce  the  preparation  required  to  produce 
workload  statistical  and  management  re¬ 
ports. 

Make  test  result  and  status  data  available 
in  a  more  timely  manner  and  in  a  format 
compatible  with  a  user's  requirements. 

Provide  information  for  more  efficient  oper¬ 
ation  of  the  Laboratory,  such  as  uncerti¬ 
fied  results  reports,  uncollected  specimen 
reports,  etc. 

Provide  consistent  identification  of  patient 
results. 

Facilitate  the  accuracy  of  test  results  by 
providing  drug/Laboratory  interaction  data 
and  the  flagging  of  results  outside  the 
normal  range  of  values. 

Provide  more  extensive  quality  control  re¬ 
ports  with  less  user  intervention. 

Facilitate  reduction  of  the  number  of  out¬ 
dated  blood  product  inventory  control. 

Improve  blood  donor  services  by  providing 
on-line  donor  files  and  reports. 

Improve  the  control  of  blood  product  distri¬ 
bution  by  providing  on-line,  detailed  data 
about  the  donor,  blood  product  and  patient. 

Provide  more  accurate  tracking  of  Tumor  Reg¬ 
istry  reporting  capability. 

Provide  support  for  the  Drug  Testing  Pro- 


Figure  2.2.  CHCS  laboratory  objectives  [42,  p.  2-3] 
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CHAPTER  III 

REQUIREMENTS  YET  TO  BE  FULLY  SUPPORTED 

In  spite  of  the  emphasis  placed  on  the  development  of 
laboratory  systems,  there  remain  several  important  re¬ 
quirements  which  have  not  yet  been  fully  supported  by  the 
systems.  Some  of  these  requirements  appear  to  have  been 
overlooked  completely,  while  others  address  the  issue  but 
fail  to  be  powerful  or  flexible  enough  to  handle  the  prob¬ 
lems  as  they  typically  occur.  Both  the  VADHCP  and  the 
CHCS  represent  great  strides  in  recognizing  these  require¬ 
ments  and  will  be  the  major  focus  of  attention  in  the  fol¬ 
lowing  discussions,  since  one  of  these  two  systems  will 
most  likely  be  the  one  Air  Force  laboratories  will  be  us¬ 
ing.  The  requirements  listed  represent  those  that  even 
these  two  systems  fall  short  of  supporting,  as  determined 
by  the  FDs.  Obviously,  laboratory  managers  may  find  other 
requirements  which  the  systems  do  not  adequately  support 
when  the  systems  are  subjected  to  real-life  use  and  this 
fact  must  always  be  considered.  It  must  also  be  recog¬ 
nized  that  at  the  time  of  this  writing,  most  Air  Force 
laboratories  have  no  computer  support  at  all  and  will  not 


have  any  for  several  years*  until  either  the  VADHCP  or  the 


CHCS  is  installed  and  running  smoothly.  Therefore,  all 
the  other  functions  beyond  those  listed  explicitly  in  this 
chapter  also  comprise  unmet  requirements  for  these  labora- 
tories.  The  stand-alone  system  recommended  by  this  paper 
represents  the  only  laboratory  information  system  avail¬ 
able  in  the  interim. 


With  the  advent  of  more  powerful  computers  and  the 
lessons  learned  with  each  new  generation  of  laboratory 
computer  systems,  successive  systems  are  able  to  incorpo¬ 
rate  more  modules  designed  to  assist  in  laboratory  admin¬ 
istration.  A  good  example  of  this  is  the  improvement  of 
the  ad  hoc  report  generation  capabilities  in  the  VADHCP 
relative  to  TRILAB.  The  ever-increasing  flexibility  of 
each  new  system  is  evidence  of  the  designers'  recognition 
that  the  programs  cannot  anticipate  every  use  a  particular 
laboratory  may  have  for  the  system.  Allowing  access  to 
the  program  and  to  its  associated  databases  may  allow  the 
end  user  to  solve  many  of  the  problems  inherent  in  older 
systems,  but  this  presumes  the  presence  of  a  user  who  un¬ 
derstands  both  the  system  and  the  problems  well  enough  to 
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make  the  proper  modifications  without  compromising  the 
system  as  a  whole.  This  access  also  presumes  that  the 
system  has  the  basic  abilities  necessary  to  support  the 
modifications.  Very  few,  if  any,  laboratories  currently 
have  access  to  both  of  these  resources.  Whether  each  lab¬ 
oratory  will  have  them  in  the  future  is  speculative,  but 
it  is  safe  to  assume  that  each  laboratory  has  need  of  them 
now. 

In  examining  some  of  the  tools  which  are  useful  to 
the  laboratory  management,  consideration  must  be  given  to 
what  is  currently  available  and  what  is  expected  to  be 
available  in  the  future.  It  has  already  been  established 
that  the  typical  military  laboratory  has  much  in  common 
with  civilian  facilities  in  terms  of  daily  tasks  and  that 
there  also  exist  some  tasks  unique  to  the  function  of  a 
military  laboratory.  With  a  few  notable  exceptions,  such 
as  the  proposed  support  for  the  Drug  Testing  Program  sup¬ 
port  available  with  the  CHCS,  the  large  systems  are  being 
designed  much  like  civilian  hospital  support  systems.  It 
is  left  to  the  user  and  local  creativity  to  handle 
extraordinary  military  circumstances.  Such  circumstances 
seldom  have  anything  to  do  with  the  laboratory  and  would 
not  even  be  construed  to  be  part  of  a  laboratorian's  job 
in  the  civilian  world;  in  the  military,  however,  one's 
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laboratory  duties  are  subordinate  to  duties  as  defined  by 
higher  authority.  In  this  way,  the  laboratory  and  its 
technologists  can  become  an  Office  of  Primary  Re¬ 
sponsibility  (OPR)  for  any  number  or  type  of  extra  duties. 
Examples  might  include  being  designated  as  project  officer 
for  solicitation  drives  such  as  the  Combined  Federal  Cam¬ 
paign,  as  a  disaster  preparedness  team  chief,  or  as  the 
manager  of  the  local  emergency  shelter.  A  truly  respon¬ 
sive  laboratory  information  system,  then,  should  be  a  tool 
in  managing  these  completely  unrelated  duties,  if  desired, 
as  well  as  laboratory  responsibilities. 

Personnel 

One  of  the  most  interesting,  and  often  most  frustrat¬ 
ing,  activities  of  a  laboratory  manager  is  the  scheduling 
of  the  laboratory  manpower.  As  in  a  civilian  laboratory, 
care  must  be  taken  to  insure  fair  and  equal  treatment  of 
the  staff.  For  example,  the  manager  must  make  the  typical 
decisions  regarding  ability,  competency,  compatibility  of 
co-workers,  seniority,  periodic  rotations,  scheduled  con¬ 
tinuing  medical  education  (CME) ,  personal  preferences,  and 
emergencies.  In  addition,  however,  the  manager  must  con- 


sider  leave^,  sick  time^,  scheduled  military  training, 
temporary  duty  (TDY)  elsewhere,  and  frequent  changes  to 
the  staff  as  a  result  of  transfers  to  and  from  other  in¬ 
stallations  (PCR--permanent  change  of  station) .  Fortu¬ 
nately,  payroll  seldom  comes  into  play,  since  all  military 
workers  are  salaried.  However,  the  pay,  benefits,  and 
hours  worked  by  civilian  government  employees  are  regu¬ 
lated  by  law  and  by  union  agreements  and  must  be  carefully 
controlled.  With  all  this  to  consider,  developing  a  peri¬ 
odic  manpower  schedule  becomes  difficult,  and  an  error 
will  generally  translate  into  extra  work  for  someone.  A 
properly  designed  information  system  appropriate  to  the 
personnel  requirements  of  the  laboratory  will  not  only 
maintain  data  such  as  appointments  and  scheduled  absences, 
current  leave  balances,  projected  gains  and  losses,  indi- 


^■By  law,  every  active  duty  member  accrues  2.5  days  of 
leave  (paid  vacation)  per  month  on  active  duty.  He  can 
carry  no  more  than  60  days  into  the  next  fiscal  year, 
which  currently  begins  on  1  October  of  each  year?  any  ex¬ 
cess  is  lost  forever.  Any  such  loss  requires  thorough 
justification.  The  member  and  his  supervisor  are  equally 
responsible  for  seeing  that  no  leave  is  lost. 

2Sick  time  is  not  an  accrued  benefit  for  military 
members.  If  a  member  is  declared  unable  to  work  by  compe¬ 
tent  medical  authority,  or  if  such  authority  declares  that 
the  work  routine  must  be  altered,  these  declarations  are 
carried  out.  There  are  no  alterations  to  the  member's  pay 
or  benefits;  the  only  effect  on  the  laboratory  is  the  ex¬ 
tra  workload  placed  on  the  remaining  technologists. 
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vidual  competencies,  and  working  times  available  for  each 
technologist,  but  will  also  design  suitable  work  schedules 
using  this  data. 

Of  the  four  laboratory  systems  discussed  in  Chapter 
Two,  only  the  CHCS  makes  any  mention  of  personnel  schedul¬ 
ing  support  [42,  p.  2-14). 

2.4.9  Administrative  Support.  These  capabili¬ 
ties  will  provide  the  workload  statistics  to 
meet  the  Uniform  Chart  of  Accounts  (UCA) ,  and 
the  CAP  (College  of  American  Pathology  [sic] ) 
workload  reporting  requirements.  UCA  weighted 
procedures  totals  will  be  provided  for  Clinical 
Pathology,  Anatomical  Pathology,  and  Blood  Bank. 

The  system  will  produce  CAP  Detail,  Summary,  and 
Comparison  Reports  for  a  user-specified  time  pe¬ 
riod.  Service-unique  manpower  reporting  re¬ 
quirements  (e.g.  [sic] .  ARMY  Schedule  X)  and 
personnel  scheduling  will  also  be  supported  by 
the  system. 

There  is  obviously  no  indication  as  to  the  degree  of  sup¬ 
port  the  system  offers,  but  among  the  related  output  re¬ 
quirements  are  found  "LAB-PERSONNEL-SCHEDULE *  and  "LAB- 
SCHEDULE-TEMPLATE-DISPLAY"  [42,  p.  3-4]. 

In  addition  to  personnel  scheduling  is  the  mainte¬ 
nance  of  the  local  personnel  files.  None  of  the  systems 
discussed  thus  far  offers  any  direct  support  of  this  func¬ 
tion.  Although  only  a  small  part  of  a  member's  personnel 
file  is  maintained  in  the  laboratory,  it  is  the  most  dy¬ 
namic  part.  This  file  will  contain  the  member's  on-the- 
job-training  (OJT)  record,  certifications  records,  CME 
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documentation,  performance  evaluations,  documentation  of 
counseling  sessions,  laboratory  assignments,  commenda¬ 
tions,  and  any  other  information  which  the  supervisor 
wishes  to  keep.  None  of  the  information  will  be  classi¬ 
fied,  of  course,  but  it  should  be  considered  confidential. 
Good  management  practices  generally  dictate  that  activi¬ 
ties  such  as  evaluations,  counseling,  and  training  be  per¬ 
formed  regularly  as  well  as  on  an  as-needed  basis.  At  the 
discretion  of  the  manager,  the  laboratory  information  sys¬ 
tem  should  be  capable  of  providing  notification  that  such 
activities  are  coming  due,  and  even  provide  time  for  them 
in  the  schedule,  if  desired.  The  system  should  also  be 
able  to  maintain  this  information  in  a  file  or  database 
which  is  appropriately  secure  from  unauthorized  access. 


Cost  Analysis  and  Justification 


When  consideration  is  given  to  acquiring  new  instru¬ 
mentation,  making  a  new  test  available,  discontinuing  an 
expensive  or  seldom-requested  procedure,  altering  an  es¬ 
tablished  procedure,  or  requesting  additional  personnel  to 
alleviate  a  manpower  shortage,  the  entire  process  ulti¬ 
mately  boils  down  to  a  discussion  of  need  versus  cost  ver¬ 
sus  benefit.  Sometimes  this  process  is  relatively  simple. 
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such  as  using  the  FASCAP  program  to  acquire  a  piece  of 
equipment  which  pays  for  itself  by  fulfilling  an  existing 
function  less  expensively.  In  this  case,  the  need  is  al¬ 
ready  established,  the  relative  cost  will  be  zero  or  less, 
and  the  benefit  is  left  to  the  laboratory  to  determine. 
More  often,  however,  the  manager  finds  himself  having  to 
justify  all  three  of  these  parameters.  Usually,  document¬ 
ing  the  need  for  a  new  item  is  the  most  difficult  of  the 
tasks.  The  military  is  unique  in  that  an  item  must  be 
needed  before  it  can  be  pursued ;  a  projected  requirement 
is  of  little  or  no  worth.  This  situation  makes  it  easy  to 
rationalize  that  if  the  laboratory  has  "needed"  the  item 
for  the  past  year  but  has  somehow  managed  to  get  along 
without  it,  no  need  really  existed.  As  a  result,  this 
need  must  usually  be  documented  by  translation  to  a  cost 
savings. 

The  FD  for  the  CHCS  specifies  that  the  CHCS  be  able 
to  maintain  inventory  data  for  the  laboratory,  including 
the  costs  of  supplies  [42,  p.  3-39];  no  such  specification 
exists  for  the  VADHCP.  Presumably,  such  information  as 
cost  per  test  and  net  worth  could  be  derived  using  inven¬ 
tory,  workload,  and  procedure  data,  but  this  would  repre¬ 
sent  only  historical  information.  Extrapolation  of  antic¬ 
ipated  future  performance,  modeling  of  new  procedures  un- 


der  consideration,  and  comparisons  of  the  related  studies 
would  still  have  to  be  done  externally.  In  describing  a 
stand-alone  program  used  to  derive  the  actual  cost  of  a 
given  test,  Sealfon  lists  20  items  which  should  be  consid¬ 
ered  [37,  p.  426], 

1.  Price  per  kit  or  total  reagent^  costs. 

2.  Number  of  tests  per  kit  or  total  reagent 

volume. 

3.  Number  of  controls^  per  run. 

4.  Number  of  standards 5  per  run. 

5.  Single  or  replicate  analysis. 

6.  Price  for  expendable  items  per  batch. 

7.  Price  for  expendable  items  per  specimen. 

8.  Specimen  collection  and/or  processing  costs. 

9.  Maximum  batch  size  (instrument-dependent). 

10.  Calculated  time  per  analytical  result  or 
CAP  workload  factor. 

11.  Technologist  hourly  salary. 

12.  Reference  laboratory  or  selected  comparison 
price. 

13.  Frequency  of  calibration. 

14.  Number  of  replicate  calibrators  required 
for  calibration. 

15.  Number  of  actual  work  days  per  month. 

16.  Initial  instrument  purchase  price. 

17.  Instrument  useful  life  span  (years). 

18.  Instrument  salvage  value. 


^Reagents  are  the  chemicals  required  to  do  the  test. 

^Controls  are  laboratory  samples  which  are  tested  at 
the  same  time  and  in  the  same  way  as  the  patient  samples, 
and  whose  values  must  fall  into  a  statistically  determined 
range  for  the  test  to  be  considered  valid. 

^Standards  are  samples  of  known  value  tested  with  the 
patient  and  control  samples.  The  values  of  the  control 
and  patient  samples  can  be  calculated  using  this  known 
standard  value  and  the  raw  data  from  the  testing  environ¬ 
ment. 
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19.  Total  nvunber  of  different  analytes®  per¬ 
formed  daily  on  the  instrument. 

20.  Yearly  maintenance  costs  (service  con¬ 
tract)  . 

It  can  be  seen  that  some  of  these  may  not  be  immediately 
available  to  the  CHCS  database,  which  would  require  exter¬ 
nal  manipulation. 


Computer-Aided  Instruction 


Computer-aided  instruction  (CAI)  has  only  recently 
been  considered  as  appropriate  for  laboratory  instruc¬ 
tional  use.  According  to  Burson,  "Computer  Assisted  In¬ 
struction  (CAI),  in  its  simplest  'definition'  sense,  is  an 
interactive  learning  environment  in  which  the  computer 
makes,  facilitates  and  implements  the  final  information 
presentation  based  on  input  from  the  learner"  [5,  p.  886]. 

It  is  easily  recognized  that  a  modern  Medical  Technologist 
"must  understand  the  basics  of  computer  science  as  they 
relate  to  the  medical  laboratory"  [43,  p.  663],  But  using 
computers  as  substitutes,  at  least  to  some  extent,  for 
traditional  lectures  and  programmed  learning  texts  ap- 

' 

f 

peared  to  be  a  somewhat  radical  way  to  introduce  students  i1 


®The  analyte  is  the  particular  substance  in  the  sam¬ 
ple  being  tested  for.  For  example,  glucose  is  the  analyte 
of  a  blood  sugar  test. 

♦ 
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to  computers.  However,  CAI  in  the  laboratory  training  en¬ 
vironment  appears  to  be  successful.  In  one  study  compar¬ 
ing  CAI  to  lectures  and  programmed  learning  texts  [10], 
those  students  using  CAI 

(1)  were  less  likely  to  be  bored, 

(2)  showed  increased  achievement, 

(3)  had  considerably  lower  failure  rates,  and 

(4)  saved  a  lot  of  time. 

None  of  the  four  military  laboratory  systems  has  or 
is  anticipated  to  have  a  documented  CAI  capability,  but  it 
is  arguable  that  CAI  could  be  emulated  through  clever  ma¬ 
nipulation  of  specialized  databases,  report  generation, 
and  data  input.  Only  a  few  laboratories  actively  train 
technologists  and  technicians,  but  all  laboratories  have  a 
need  for  continuing  education  and  for  indoctrination  of 
recently-arrived  technologists. 

Correspondence 

In  addition  to  the  many  reports  which  a  laboratory 
manager  must  submit,  there  will  forever  exist  a  tremendous 
amount  of  information  which  must  be  transmitted  using 
printed  prose.  Very  few  laboratories  have  their  own 
secretarial  support  and,  unfortunately,  laboratory 
correspondence  seldom  receives  high  priority  when  submit- 


ted  to  a  typing  pool.  Especially  in  the  smaller  labora¬ 
tory,  a  document  requiring  typing  must  either  be  typed  by 
the  originating  individual  or  created  in  draft  form  to  be 
typed  by  an  assigned  laboratorian  if  deadlines  are  to  be 
met. 

The  advent  of  word  processing  has  drastically  reduced 
the  amount  of  time  needed  to  produce  a  correct  final  copy 
of  a  document.  There  is  of  course  no  speed  advantage  in 
the  actual  typing  of  the  document,  since  that  speed  is  de¬ 
pendent  on  the  abilities  of  the  typist.  However,  making 
an  error  does  not  require  restarting  the  entire  page.  The 
abilities  of  a  full-featured  word  processor  make  composi¬ 
tion  at  the  keyboard  and  later  revisions  easy,  eliminating 
the  time  needed  to  create  a  draft.  Sizing  text  to  fit 
into  a  defined  area,  as  on  an  APR  or  OER,  becomes  much 
less  of  a  chore  and  much  faster.  The  final  product  will 
often  be  more  professional  as  a  result  of  on-line  thesauri 
and  spell -checking  routines. 

Another  advantage  realized  when  using  word  processing 
is  that  of  maintaining  large  documents  on  quickly  accessi¬ 
ble  media.  Much  time  and  effort  can  be  saved,  for  exam¬ 
ple,  by  producing  and  keeping  procedure  manuals  on  mag¬ 
netic  disks  as  well  as  on  paper  at  the  work  areas.  When¬ 
ever  a  procedure  requires  a  change,  the  source  document 
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can  be  quickly  retrieved  from  the  disk,  updated,  edited. 


and  replaced  on  the  disk.  The  computer  then  prints  the 


updated  pages  to  replace  the  ones  at  the  work  area  after 


review  by  the  laboratory  manager.  Because  of  this  ease  in 


changing  a  source  document,  however,  the  Air  Force  does 


not  recognize  the  storage  medium  as  a  copy  of  a  document. 


Thus,  for  those  documents  requiring  a  file  copy,  multiple 


copies  of  the  document  must  be  printed  with  the  original. 


Automatic  Notification 


As  in  most  modern  enterprises,  there  exists  in  the 


laboratory  a  plethora  of  dates  and  times  representing  some 


required  or  desired  action.  Many  of  these  were  discussed 


above  in  conjunction  with  personnel  management,  but  there 


remain  many  others.  It  is  a  very  simple  matter  for  a  com¬ 


puter  to  be  provided  with  these  dates,  times,  and  activi¬ 


ties  as  data  and  give  some  sort  of  notification  when  ac¬ 


tion  is  due.  Even  better,  it  can  prompt  the  user  for  in¬ 


terim  checkpoints  to  avoid  last-second  rushes.  Assigning 


a  relative  priority  to  each  activity  further  enhances  the 


computer's  ability  to  assist  in  the  manager's  planning  of 


daily,  weekly,  or  monthly  events.  The  system  could  then 


be  used  as  a  daily  work-list  generator  for  the  manager  in 
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much  the  same  way  as  it  generates  work  lists  for  the  tech¬ 
nologists.  The  list  of  activities  is  virtually  endless, 
but  would  include  all  the  recurring  personnel  management 
functions  noted  earlier,  patient  appointments,  meetings, 
projects,  suspenses,  correspondence  awaiting  replies,  ob¬ 
stetric  patients'  due  dates,  and  even  technologists' 
birthdays.  Any  event  sufficiently  important  to  the  user 
can  be  included. 

Many  recurring  activities  in  the  processing  area  of 
the  laboratory  are  required  for  accreditation  and  Droper 
operation.  The  CHCS  has  a  provision  for  documenting  the 
routine  scheduled  preventive  maintenance  of  equipment  and 
maintain  a  repair  log  [42,  p.  2-14],  but  there  is  no  indi¬ 
cation  that  the  system  will  prompt  the  technologist  when 
maintenance  is  due.  Since  these  records  are  seldom  con¬ 
sulted  unless  the  instrument  fails,  such  an  ability  will 
likely  decrease  the  number  of  times  routine  maintenance  is 
overlooked. 


Professional  Needs 

Small  computers  offer  many  capabilities  useful  to  a 
Medical  Technologist  as  he  performs  consultations  or  other 
duties  associated  with  his  training  in  clinical  pathology. 
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Many  small  Air  Force  hospitals  and  clinics  do  not  have  a 
pathologist  on  the  staff  and  it  falls  upon  the  laboratory 
chief  to  provide  such  support,  either  by  offering  his  own 
services  to  the  extent  his  training  and  credentials  allow 
or  securing  the  services  of  a  qualified  reference  patholo¬ 
gist.  These  services  can  be  divided  into  at  least  two 
general  categories,  diagnosis  and  research. 


Computer-Aided  Diagnosis 


Research  in  artificial  intelligence  has  demonstrated 
that  programs  can  be  developed  for  computers  which  make 
these  systems  act  as  experts  in  some  field  of  understand¬ 
ing.  Rich  defines  such  expert  systems  [35,  p.  284] . 

There  is  a  whole  array  of  interesting  tasks 
.  .  .  that  require  a  great  deal  of  specialized 
knowledge  that  most  people  do  not  possess. 

These  tasks  can  only  be  performed  by  experts  who 
have  accumulated  the  required  knowledge.  Exam¬ 
ples  of  such  tasks  include  medical  diagnosis, 
electronic  design,  and  scientific  analysis. 
Programs  to  perform  these  tasks  would  be  very 
useful  since  there  is  usually  a  shortage  of 
qualified  human  experts.  Programs  that  do  per¬ 
form  some  of  these  tasks  have  already  been  writ¬ 
ten.  Such  programs  are  called  expert  systems 
and  the  construction  of  them  is  referred  to  as 
knowledge  engineering. 
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Among  medical  diagnosis  systems,  programs  such  as  IN¬ 
TERN  and  MYCIN?  have  served  as  templates  for  similar  pro¬ 
grams  available  now  which  run  on  microcomputers.  Although 
physician  acceptance  of  such  diagnostic  sources  varies, 
such  a  system  can  offer  valuable  assistance  to  the  labora- 
torian  in  explaining  unusual  laboratory  values  and  sug¬ 
gesting  confirmatory  studies.  It  can  also  serve  as  a  use¬ 
ful  resource  for  any  interested  physician  in  his  nonlabo¬ 
ratory-related  diagnoses  and  as  a  diagnostic  training 
tool . 

No  formal  computer-aided  diagnosis  ability  is  part  of 
any  of  the  current  or  proposed  military  medical  laboratory 
systems.  Access  to  the  databases  is  to  be  granted  by  the 
VADHCP  and  the  CHCS,  but  neither  the  specialized  knowledge 
bases  nor  the  "analytical  engine"  required  could  be 
incorporated. 

Research 

Although  funds  for  research  are  seldom  granted  to 
small  laboratories,  the  Air  Force  encourages  research  at 

^INTERN  is  a  program  which  asks  questions  of  the 
clinician  and  forms  a  differential  diagnosis  based  on  his 
responses  and  on  its  knowledge  base.  MYCIN  is  similar, 
but  specializes  in  diagnosing  bacterial  infections. 
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all  levels  as  a  learning  tool  and  a  technical  resource. 
Even  the  smallest  laboratory  will  eventually  be  called 
upon  to  pursue  unusual  circumstances  surrounding  an  occa¬ 
sional  patient  or  assist  a  physician  in  writing  a  paper. 
A  laboratorian  may  want  to  pursue  an  area  of  interest  him¬ 
self,  perhaps  in  preparation  for  a  presentation  or  publi¬ 
cation  of  a  paper.  In  any  case,  the  abilities  available 
with  small  computers  can  present  options  to  the  research 
not  otherwise  available. 

During  the  course  of  the  project,  databases  contain¬ 
ing  the  associated  information  will  be  created.  These 
databases  may  contain  preparatory  material  or  data  gath¬ 
ered  during  the  actual  performance  of  the  experimentation. 
Conceivably,  the  data-handling  capabilities  of  the  VADHCP 
or  the  CHCS  could  be  tapped  to  perform  this  function. 
However,  other  sources  of  information  must  be  manually  en¬ 
tered.  An  example  of  this  is  access  to  MEDLINE^  or  to  an 
automated  library  cataloging  system.  A  microcomputer 
equipped  with  an  inexpensive  modem  could  access  such  re¬ 
sources  directly.  This  capability  is  not  documented  in 
the  FDs  for  the  major  systems. 

®MEDLINE  is  an  automatic  search  system  for  medical 
journal  entries.  By  using  key  words  and  Boolean  logic 
("and,"  "or,"  and  "not"),  papers  relating  to  the  desired 
topic  can  be  selected. 


i 
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CHAPTER  IV 

STAND-ALONE  SYSTEM  ANALYSIS 


The  production  of  a  large-scale  laboratory  or  hospi¬ 
tal  computer  system  obviously  involves  much  planning  and 
organizing  before  the  system  can  be  constructed.  Weinberg 
calls  these  efforts  the  analysis  phase,  which  is  followed 
by  the  design  and  implementation  phases  if  the  project 
continues  to  its  completion  {44,  pp.  10-11], 

Analysis  frequently  is  used  to  describe  the 
front-end  phase  of  the  systems  development  life 
cycle  prior  to  the  design  phase.  In  this  phase, 
problems  and  objectives  are  defined,  tentative 
solutions  proposed,  and  costs  and  benefits  eval¬ 
uated. 

One  can  debate  whether  the  laboratory  systems  presented  in 
Chapter  Two  are,  or  will  be,  the  result  of  a  proper  analy¬ 
sis  as  defined  by  the  experts.  This  paper  will  not  enter 
into  this  debate  other  than  to  recognize  that  proper  anal¬ 
ysis  is  necessary  to  the  success  of  the  system.  The  exis¬ 
tence  of  FDs  for  the  CHCS  indicates  that  an  attempt  was 
made. 


One  of  the  primary  concerns  of  a  systems  analyst  is 
to  be  familiar  with  the  intended  operations  of  the  organi- 
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zation  in  question.  One  of  his  best  sources  for  this  in¬ 
formation  is  the  end  user,  the  one  who  will  be  ultimately 
running  the  system  and,  hopefully,  benefiting  from  its  op¬ 
erations.  In  the  case  of  the  CHCS,  the  end  user  becomes 
generic  because  of  the  intended  total  integration  of  the 
system.  To  take  into  account  the  needs  and  desires  of 
each  end  user  of  such  a  system  becomes  counterproductive. 
Therefore,  the  analysis  keys  upon  the  known  equivalencies 
from  laboratory  to  laboratory  and  specific  augmentations 
are  left  to  the  creativity  of  the  local  management. 


Data  Flow  in  the  Laboratory 


One  of  the  first  aspects  of  the  organization  which 
the  analyst  attempts  to  understand  is  the  kinds  of  data 
used,  where  the  data  come  from,  how  they  flow  through  the 
organization,  how  they  are  changed  during  this  flow,  and 
where  they  ultimately  terminate.  A  tool  used  by  the  ana¬ 
lyst  to  chart  these  properties  is  the  data  flow  diagram 
(DFD)l.  Figure  4.1  is  an  extremely  simplified  DFD  tracing 
some  of  the  data  associated  with  a  typical  physician's 


^-Weinberg  defines  a  DFD  as  "a  graphic  tool  used  to 
depict  the  logical  flow  of  data  through  a  program  or  sys¬ 
tem"  [44,  p.  55]  and  "a  graphic  tool  that  represents  data 
flow  and  transforms  in  a  process"  (44,  p.  311]. 
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Figure  4.1.  General  top-level  DFD  for  a  laboratory  analy¬ 
sis  request. 


order  through  a  laboratory.  Because  Air  Force  laborato¬ 
ries  conform  to  civilian  accreditation  requirements,  this 
DFD  applies  to  Air  Force  laboratories  as  well.  It  must  be 
noted  that  there  exist  many  extensions  to  this  DFD  which 
describe,  for  example,  report  generation,  maintenance, 
specimen  shipment  and  receipt  of  results,  and  inventory. 
In  addition,  the  entire  DFD  can  be  depicted  to  many  more 
levels^.  If  extensions  are  then  added  to  cover  the  data 
flows  associated  with  the  standard  military  operations  of 
a  DoD  laboratory,  one  can  conceive  of  the  DFD  which  the 
CHCS  (hopefully)  has  been  designed  to  support. 

In  addition  to  the  typical  workload  flow,  every  labo¬ 
ratory  faces  data  which  must  be  handled  in  a  nonstandard 
or  undefined  way.  Although  the  military  attempts  to  stan¬ 
dardize  its  operation  as  much  as  possible  through  the  use 
and  enforcement  of  documented  regulations,  a  given  manager 
is  seldom  familiar  with  those  regulations  outside  his  own 
realm.  The  regulations  may  also  not  cover  a  specific  sit¬ 
uation  or  may  explicitly  place  the  responsibility  for  the 

^Each  circle  (known  as  a  "transform"  or  "bubble") 
represents  some  activity  performed  to  change  the  incoming 
data  into  the  outgoing  data.  The  methods  by  which  this 
transformation  takes  place  can  also  be  represented  by  a 
DFD.  Therefore,  a  DFD  can  be  fully  characterized  to  any 
desired  degree  of  detail  by  successive  descriptions  of 
transforms.  A  level  or  layer,  then,  represents  the  next 
degree  of  detail  in  the  DFD. 
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decision  on  the  manager  without  further  guidance.  In  any 
case,  handling  the  flow  of  data  associated  with  such 
crises  essentially  becomes  the  responsibility  of  the  man¬ 
ager.  As  a  result,  a  DFD  describing  this  general  situa¬ 
tion  cannot  be  any  more  detailed  than  the  one  in  Figure 
4.2.  The  layers  and  extensions  of  the  transform  literally 
do  not  exist  until  the  situation  occurs  for  the  first 
time.  Naturally,  the  number  of  options  available  to  the 
manager  as  he  approaches  the  problem  will  be  greatly  in¬ 
fluenced  by  the  flexibility  of  the  tools  he  plans  to  use. 
And  there  can  be  no  argument  that  the  information  systems 
in  the  laboratory  are  important  tools. 


RECOGN I  ZED 
AUTHOR  I  TV 


DFD  for  an  atypical  laboratory  duty. 
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(MS-DOS-* ) ,  which  can  loosely  be  considered  to  be  the  IBM4 
Personal  Computer  (PC) ,  the  IBM  PC/XT,  the  IBM  Personal 
Computer  AT® ,  and  their  true  compatibles®.  It  should  be 
noted  here  that  the  Zenith  Z-248 ^ ,  the  "advanced  computer 
system"  for  which  the  Air  Force  let  a  standard  require¬ 
ments  contract  in  February  of  1986,  is  required  to  be  AT 
compatible  [1,  pp.  68-70] .  This  group  of  microcomputers 
is  well  established  in  the  business  world  and  have  indeed 
created  a  de  facto  standard  for  microcomputers.  For  these 


Microsoft  Corporation,  Bellevue,  Washington. 

international  Business  Machines  Corporation,  Boca 
Raton,  Florida. 

5The  IBM  PC  is  the  basic  microcomputer  using  Intel's 
8088  microprocessor.  The  IBM  PC/XT  is  essentially  identi¬ 
cal  to  the  PC,  but  h?s  the  necessary  modifications  to  eas¬ 
ily  support  popular  add-in  options  such  as  hard  disk 
drives.  The  IBM  Personal  Computer  AT  is  based  on  Intel's 
80286  microprocessor,  which  runs  at  a  higher  clock  speed 
and  can  directly  address  more  memory.  Since  the  instruc¬ 
tion  set  of  the  80286  is  a  superset  of  the  8088,  it  can 
run  the  same  software  as  the  8088-based  systems. 

® Since  the  firmware -based  routines  (ROM  BIOS)  in  the 
IBM  machines  are  copyrighted,  the  compatibles  (also  known 
as  clones)  must  emulate  these  routines  in  their  own  soft¬ 
ware  or  firmware.  The  success  of  this  emulation  varies 
from  clone  to  clone  with  a  concomitant  variation  in  their 
abilities  to  run  all  the  same  software  despite  having 
identical  microprocessors.  On  the  positive  side,  many 
clones  incorporate  later  microprocessor  versions,  such  as 
the  8088-2  or  8088-3,  which  run  at  much  higher  clock 
speeds.  Some  AT  clones  will  also  accept  the  80386,  which 
will  be  widely  available  soon. 

^Zenith  Data  Systems  Corporation,  Vienna,  Virginia. 


reasons,  the  reader  is  referred  to  other  appropriate 
sources  for  information  regarding  their  use  in  a  nonlabo¬ 
ratory  setting.  In  the  laboratory,  of  course,  some  spe¬ 
cial  precautions  must  be  taken.  However,  with  a  few  ex¬ 
ceptions,  these  precautions  will  be  very  similar  to  those 
taken  for  other  microprocessor-controlled  instruments 
which  are  usually  abundant  in  a  modern  laboratory. 

Envi ronment 

The  Air  Force  laboratory  environment  varies  little 
when  compared  to  its  civilian  counterparts.  Both  types 
suffer,  or  benefit,  from  constants  such  as  the  age  of  the 
facility,  the  state  of  repair  of  the  building  and  fix¬ 
tures,  the  amount  of  workspace  available,  and  convenient 
access  to  the  various  departments.  These  constants  then 
combine  to  affect  the  variables  under  which  the  system 
must  operate,  such  as  heat,  humidity,  vibration,  proximity 
to  liquid,  gaseous,  or  microbial  contamination,  working 
light,  glare,  and  electrical  power  stability.  These  same 
variables  affect  the  daily  work  of  a  laboratory,  not  only 
in  terms  of  sensitive  equipment,  but  also  in  the  biochemi¬ 
cal  processes  themselves.  Fortunate  indeed  is  the  labora- 


torian  whose  quality  control  records  do  not  show  the  re¬ 
sults  of  an  air  conditioning  failure. 

A  typical  microcomputer  and  its  peripherals  will  eas¬ 
ily  tolerate  the  normal  conditions  found  in  a  laboratory 
with  appropriate  care.  Figure  4.3  outlines  some  of  the 
documented  tolerances  for  a  typical  microcomputer  system. 
Recently  built  laboratories  are  often  devoid  of  exterior 
doors  and  windows  and  rely  solely  on  their  own  air-han¬ 
dling  systems  to  maintain  the  temperature  and  humidity 
within  acceptable  tolerances.  To  lessen  the  chance  of 
contamination,  the  air-handling  system  for  the  laboratory 
ideally  should  be  isolated  from  that  of  the  rest  of  the 
hospital  and  should  maintain  a  slightly  negative  pressure 
relative  to  the  hospital.  This  certainly  is  not  always 
the  case,  but  it  often  contributes  to  a  lessening  of  the 
ability  of  the  air-conditioning  system  to  dissipate  the 
heat  generated  by  all  the  laboratory  equipment.  In  addi¬ 
tion,  large  temperature  variations  can  be  expected  in  var¬ 
ious  parts  of  the  laboratory,  but  drastic  temperature 
changes  can  normally  be  considered  unlikely.  Since  a  lab¬ 
oratory  can  seldom  tolerate  temperatures  outside  a  range 
of  approximately  13-29°C  (55.4-84.2°F)  without  experienc¬ 
ing  some  unacceptable  degradation  in  performance,  the  mi¬ 
crocomputer  will  be  outside  its  tolerances  only  in  extreme 
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Figure  4.3.  Typical  hardware  environmental  tolerances 
(24,  p.  M-2?  21,  pp.  2-4-3,  2-4-5?  6,  p.  3?  47,  p.  4?  46, 

p.  4] . 


laboratory  emergencies.  Laboratory  humidity  is  typically 
higher  than  the  ambient  humidity  for  a  given  temperature, 
but  seldom  causes  any  problems  for  hardware  unless  conden¬ 
sation  is  present.  In  areas  of  low  relative  humidity, 
however,  care  must  be  taken  to  guard  against  static  elec¬ 
tricity  discharges  through  the  equipment,  especially  if 
the  laboratory  is  successful  at  maintaining  comfortably 
low  temperatures.  Special  mats  and  touch  plates  are 
available  for  this  purpose,  and  proper  equipment  grounding 
is  mandatory  in  any  case. 

Laboratory  contamination  presents  a  unique  problem 
for  a  microcomputer.  If  the  system  is  situated  in  an  of¬ 
fice,  as  an  example,  it  must  be  protected  from  snacks  and 
pastimes  of  proximal  humans.  No  laboratory,  however, 
should  permit  eating,  drinking,  or  smoking  in  analytical 
areas,  so  a  system  placed  there  should  not  be  affected  by 
consumable  items.  Without  sacrificing  user  convenience, 
the  system  should  be  situated  out  of  the  way  of  accidental 
spills  or  splashes  of  any  substance  and  away  from  any 
source  of  corrosive  gases.  Standard  laboratory  procedures 
minimize  the  likelihood  of  any  of  these  situations  occur¬ 
ring  and  define  cleanup  regimens,  but  accidents  will  al¬ 
ways  be  part  of  laboratory  life.  Hardware  such  as  a  key¬ 
board  is  notoriously  difficult  to  clean,  and  circuit 


boards  and  disks  can  be  rendered  permanently  useless  after 
exposure  to  these  agents.  In  addition,  proper  laboratory 
technique  must  be  maintained  to  avoid  the  keyboard  becom¬ 
ing  a  vector  for  hand-borne  contamination.  Covering  the 
equipment  when  not  in  use  or  during  the  performance  of  po¬ 
tentially  messy  procedures  represents  common-sense  manage¬ 
ment. 

Electrical  power  considerations  are  generally  self- 
evident,  but  some  thought  is  necessary  before  system 
placement  is  decided  upon.  Surge-suppression  techniques 
should  always  be  employed.  If  continuous  operation  is  es¬ 
sential,  the  system  must  be  connected  to  a  line  to  which 
emergency  power  is  supplied  in  the  event  of  an  interrup¬ 
tion  of  service.  An  uninterruptible  power  supply  will 
probably  be  necessary  to  keep  the  system  running  during 
the  transition  phases.  Although  the  power  requirements  of 
even  a  fully  outfitted  microcomputer  system  are  generally 
too  low  to  present  an  unacceptable  drain  on  a  good  emer¬ 
gency  power  system,  it  may  be  sufficient  to  cause  voltage 
fluctuations  which  may  affect  itself  or  other  equipment  on 
the  same  line.  Conversely,  the  computer  system  may  not 
tolerate  fluctuations  introduced  by  the  other  equipment. 
In  addition,  care  must  be  taken  to  consider  the  effects, 
if  any,  of  the  electromagnetic  radiation  produced  by  elec- 
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trical  systems  on  or  from  other  equipment.  An  IBM  PC,  for 
example,  interferes  with  a  nearby  television  set. 

Finally,  the  system  should  be  situated  in  a  stable, 
comfortable  work  area  which  is  not  subject  to  excessive 
shock  or  vibration.  Sufficient  light  must  be  available 
without  producing  undue  glare  on  the  screen.  It  is  obvi¬ 
ous  that  the  workbench  or  desk  upon  which  the  system  is 
placed  should  be  able  to  support  its  weight  plus  a  good 
bit  more.  But  regardless  of  the  stability,  it  would  be 
unwise  to  have  the  system  share  a  bench  top  with  a  cen¬ 
trifuge,  for  example.  Even  a  well-balanced  centrifuge 
produces  sufficient  vibration  to  make  work  unpleasant;  an 
unbalanced  one  could  be  disastrous  for  the  hardware,  espe¬ 
cially  an  operating  hard  disk. 

Security 


The  Air  Force  policy  on  small  computer  systems  secu¬ 


rity  is  influenced  by  several  regulations8.  It  briefly 


8Air  Force  Regulation  (AFR)  12-35,  Air  Force  Privacy 
Act  Program;  AFR  30-30,  Standards  of  Conduct;  AFR  123-2, 
Air  Force  Fraud,  Waste  and  Abuse  (FW&A)  Prevention  and  De¬ 
tection;  AFR  125-37,  The  Resource  Protection  Program;  AFR 
205-16,  Automatic  Data  Processing  (ADP)  Security  Policy, 
Procedures  and  Responsibilities;  AFR  700-10,  Information 
Systems  Security;  and  AFR  700-26,  Acquisition  and  Manage¬ 
ment  of  Small  Computers  [20,  p.  1]. 
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states  that  the  system  is  to  be  used  properly  and  to  full 
advantage  [20,  p.  1]. 

POLICY.  (Organization  name)  personnel  will 
safeguard  and  prevent  abuse  of  small  computer 
systems  and  associated  resources  consistent  with 
established  security  policy  defined  in  this  and 
higher  level  directives,  including  the  reporting 
of  any  suspected  instances  of  fradulent  [sic]  or 
unauthorized  uses  or  practices  to  the  proper  au¬ 
thority. 

a.  Small  computer  systems  and  the  informa¬ 
tion  processed  on  those  systems  will  be  pro¬ 
tected  against  improper  use,  alteration,  manipu¬ 
lation,  or  unauthorized  disclosure  in  accordance 
with  governing  regulations. 

b.  Small  computer  systems  will  be  utilized 
to  the  fullest  extent  possible  and  only  for 
their  intended  purpose. 

This  policy  could  easily  be  applied  to  any  other  instru¬ 
ments  in  the  laboratory  as  well,  and  most  of  the  appli¬ 
cable  security  precautions  for  a  microcomputer  are  identi¬ 
cal  to  those  taken  for  other  electronic  equipment.  But  it 
must  be  noted  that  a  microcomputer  is  a  far  more  useful 
item  outside  the  laboratory  than  is  an  electrolyte  ana¬ 
lyzer9,  for  instance,  even  though  the  latter  may  be  worth 
five  times  the  value  of  the  computer.  Hence,  the  computer 
may  be  more  attractive  to  a  would-be  thief. 


typical  electrolyte  analyzer  measures  the  concen¬ 
trations  of  sodium  (Na+),  potassium  (K+) ,  chloride  (Cl~), 
and  total  carbon  dioxide  (HC0,“  +  CO,)  in  blood  or  other 
fluids.  J  * 
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Basic  to  system  security  is  what  Burch  calls 
"physical  controlled  access*  because  *if  a  potential  pene- 
trator  cannot  gain  entry  to  the  computer  facilities,  then 
the  chance  for  harm  is  reduced  considerably"  [4,  p,  466]. 
It  goes  without  saying  that  the  laboratory  should  remain 
locked  when  unoccupied  [20,  p.  1),  but  some  procedures 
must  be  adopted  to  limit  access  at  any  time  to  only  those 
individuals  to  whom  authorization  has  been  given  and  who 
pose  no  threat  to  the  system.  Intelligent  location  of  the 
system,  in  an  easily  controlled  place  which  is  suffi¬ 
ciently  isolated  to  avoid  advertising  its  existence  but  is 
conveniently  accessible  to  its  users,  will  enhance  physi¬ 
cal  security. 

Data  security  logically  demands  that  hardware,  disks, 
and  other  storage  media  be  subject  to  the  same  protection 
mechanisms  as  have  been  previously  described.  Indeed, 
Batson  feels  that  physical  security  is  still  the  best 
means  of  data  security  (2,  p.  172]. 

The  most  secure  and  best  understood  ways  of 
protecting  computers  and  their  data  are  the  old¬ 
est.  Physical  measures  such  as  locks  and  alarm 
systems  often  do  the  best  job.  Keeping  a  com¬ 
puter  system  in  a  secure  place  and  preventing 
outside  access  such  as  dial-in  phone  lines  often 
protect  a  machine  much  better  than  several  lay¬ 
ers  of  clever  programming.  As  a  bonus,  such  ar¬ 
rangements  also  help  prevent  some  "low-tech" 
hazards,  such  as  fire  damage  and  outright  theft 
of  expensive  computer  hardware. 


kfH  W*  V*  km  kTi  v  «  V«  V  •  •  »  • 
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But  the  data  on  the  media  or  in  memory  is  often  much 
more  valuable  than  the  hardware#  and  some  form  of  data 
protection  must  always  be  employed.  At  the  very  least# 
duplication  of  copyrighted  software  must  be  prevented?  on 
the  other  end  of  the  scale  lies  the  prevention  of  any  kind 
of  disclosure  during  or  after  the  manipulation  of  classi- 
fied  material.10  Patients'  sensitive  medical  information# 
which  is  affected  by  the  Privacy  Act,  falls  somewhere  in 
between  these  two  extremes.  The  type  of  data  protection 
chosen  will  necessarily  be  influenced  by  the  types  of  data 
used.  Some  authorized  system  users  may  have  to  be  denied 
access  to  certain  data  in  the  system,  and  passwords  or 
protective  software  such  as  WATCHDOG11  will  be  useful  in 
this  regard.  Generally#  however,  this  problem  is  most 
easily  solved  by  maintaining  the  information  on  removable 
media  which  are  stored  in  a  secure  area  to  which  only  the 


10When  handling  classified  data,  care  must  be  taken 
to  eliminate  any  possibility  of  compromising  the  data. 
Besides  remaining  out  of  sight  of  onlookers  and  shielding 
against  any  form  of  electromagnetic  eavesdropping  138], 
all  vestiges  of  the  data  must  be  removed  and  properly 
stored  afterward.  These  include#  but  are  not  limited  to# 
diskettes#  tapes#  notes#  papers#  printer  output#  and 
printer  ribbon.  In  addition#  all  memory  and  buffer  con¬ 
tents  must  be  destroyed#  and  monitor  burn-in  must  be  ruled 
out.  Since  data  are  not  usually  removed  from  a  disk  upon 
erasure  of  the  file#  classified  data  should  not  be  placed 
on  an  unsecurable  hard  disk. 

^Fischer  Innis  Systems  Corporation#  Naples,  Florida. 
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specified  users  have  access.  The  importance  of  creating 
and  maintaining  backup  data  cannot  be  overstated,  and  the 
backups  must  be  accorded  security  at  least  as  tight  as 
that  of  the  original.  Adherence  to  the  environmental 
guidelines  presented  previously  also  contributes  to  data 
security  by  protecting  the  system,  its  data,  and  the  stor¬ 
age  media  from  unexpected  hazards. 

A  discussion  on  Air  Force  small  computer  security  is 
not  complete  without  mentioning  fraud,  waste,  and  abuse. 
As  with  all  other  Air  Force  equipment,  the  computer  is  in¬ 
tended  for  official  use  only.  Technically,  this  precludes 
its  use  for  personal  or  nonduty  projects,  even  if  the  pro¬ 
jects  are  undertaken  entirely  during  idle  periods  and 
while  the  operator  is  off  duty.  Also  prohibited  are  bor¬ 
derline  situations,  such  as  managing  the  database  for  the 
base  Morale,  Welfare,  and  Recreation  (MWR)  bowling  league 
[25].  Hopefully,  sufficient  authority  and  responsibility 
can  be  granted  to  the  manager  of  the  computer  system  to 
judge  and  approve  each  proposed  project  on  its  own  merits. 
Only  in  this  way  can  a  microcomputer  "be  utilized  to  the 
fullest  extent  possible”  [20,  p.  1]. 


Interfacing 


In  order  for  any  computer  system  to  perform  useful 
work,  it  must  have  a  means  of  acquiring  data  from  a  source 
and  outputting  the  manipulated  data  or  information.  This 
means  is  referred  to  as  an  interface,  defined  by  Weinberg 
as  "a  common  boundary  between  two  devices,  subsys terns, 
programs,  or  modules"  [44,  p.  314].  It  can  be  thought  of 
as  a  line  of  communication  between  the  computer  and  some 
entity  exterior  to  it.  The  data  exchange  along  this  line 
must  take  place  using  some  protocol  understood  by  both  the 
computer  and  the  external  device.  The  stand-alone  labora¬ 
tory  microcomputer  system  will  definitely  have  to  inter¬ 
face  with  humans,  and  may  also  do  so  with  laboratory  ana¬ 
lytical  instruments  and/or  any  other  operating  computer 
sys terns. 

A  computer  typically  communicates  with  its  human  op¬ 
erators  through  the  written  or  typed  word.  The  exact  lan¬ 
guage  used  may  be  one  of  many  and  is  irrelevant  for  this 
discussion,  provided  both  the  computer  and  the  operator 
understand  the  language.  In  this  regard,  interaction  with 
laboratorians  is  no  different  for  the  computer  than  that 
with  nonlaboratorians .  The  typical  operator  "speaks"  with 
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the  keyboard  and  the  computer  replies  on  the  monitor  or 
printer.*2 

Interfacing  a  microcomputer  with  automated  laboratory 
instruments  presents  much  more  of  a  challenge,  but  results 
in  dramatic  increases  in  efficiency  if  properly  done.  The 
advent  of  relatively  standard  data  transmission  protocols, 
such  as  RS-232  serial  transfer,  has  greatly  improved  the 
ease  with  which  the  connections  can  be  made.  Most  modern 
microprocessor-controlled  laboratory  instruments  have 
ports  available  for  this  purpose.  Nevertheless,  special¬ 
ized  software  is  still  usually  necessary  to  allow  the  two 
devices  to  recognize  each  other.  Medlink13,  for  example, 
requires  separate  software  interfaces  be  purchased  for 
each  instrument  the  user  wishes  to  include  in  the  system 
(15],  Although  the  ability  to  link  the  microcomputer  with 
laboratory  instruments  is  attractive  on  the  surface,  the 
high  cost  and  subsequent  loss  of  system  availability  must 


120ther  common  input  devices  are  the  light  pen  and 
the  mouse.  Some  sophisticated  systems  employ  voice-recog¬ 
nition  techniques  allowing  them  to  accept  spoken  instruc¬ 
tions  and  reply  verbally. 

13Eastman  Xodak  Company,  Rochester,  New  York. 
Medlink  is  the  name  of  Kodak's  Data  Management  Network  for 
the  laboratory.  It  runs  on  the  IBM  PC/XT  or  IBM  Personal 
Computer  AT. 
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be  weighed  against  the  immediate  gains  realized  and  the 
restructuring  necessary  with  the  installation  of  the  CHCS. 

The  final  consideration  is  whether  the  computer  can 
interface  with  other  laboratory  computers  which  may  be 
currently  running.  As  with  the  laboratory  instruments 
just  discussed,  if  linkage  of  the  two  computers  is  feasi¬ 
ble,  hardware  and/or  software  interfaces  will  likely  be 
required.  However,  alternatives  do  exist.  Both  TRILAB 
and  the  VADHCP  are  provided  with  modems^-*  through  which 
access  to  the  system  can  be  achieved  after  proper  valida¬ 
tion;  presumedly,  the  CHCS  will  have  one  as  well.  Data 
transfer  is  much  slower  using  this  method,  but  should 
prove  to  be  adequate  since  the  host  machine  can  be  called 
upon  to  do  some  of  the  processing.  Although  software  is 
required  to  drive  the  modem,  several  excellent  packages 
are  available  in  the  public  domain.  Another  interfacing 
alternative  is  through  the  use  of  shared  media,  but  it  is 
unlikely  that  two  very  different  computers  can  produce 
diskettes,  for  example,  with  identical  formats  and  data¬ 
storage  protocols.  Once  again,  the  perceived  benefits 
must  be  explored  before  a  computer-computer  linkage  is  at- 


l^Modem  is  an  acronym  for  modulator-demodulator,  a 
device  necessary  to  send  data  over  common  carrier  lines, 
usually  telephone  lines. 
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tempted.  However,  modems  and  shared  media  provide  an  ex¬ 
cellent  way  for  occasional  interlaboratory  communications 
to  take  place. 


Software  Support 

The  emergence  of  the  IBM  PC  as  the  recognized  indus¬ 
try  standard  microcomputer  enticed  developers  to  write  a 
plethora  of  software  for  it.  As  a  result,  the  chance  of 
finding  an  appropriate  package  for  virtually  any  given 
purpose  is  high.  Competition  has  been  stimulated,  and 
comparative  reviews  are  abundant.  Most  individuals  who 
use  an  MS-DOS  computer  already  have  a  favorite  word  pro¬ 
cessor  or  spreadsheet,  a  fact  which  will  ultimately  influ¬ 
ence  the  selection  of  software  for  the  laboratory  stand¬ 
alone  system. 

Business  software  can  be  loosely  categorized  into 
five  groups:  word  processors,  spreadsheets,  database  man¬ 
agement  systems,  communications  programs,  and  programming 
environments.  Some  well-known  exanroles  of  these  groups 
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are  WordStar15,  Lotus  1-2-316,  dBase  III17,  Smartcom  II18, 
and  Turbo  Pascal15,  respectively.  Some  packages  combine 
these  five  areas  into  a  single  program.  Although  this  in¬ 
tegration  is  convenient  in  that  the  applications  are  imme¬ 
diately  available  and  data  are  easily  shared  among  them, 
these  programs  require  more  memory  and  any  given  applica¬ 
tion  is  seldom  as  powerful  as  a  single  dedicated  program. 
The  most  popular  example  of  such  an  integrated  package  is 
Symphony20,  but  another  example.  Enable21,  is  to  be  of¬ 
fered  as  part  of  the  standard  requirements  contract  [1,  p. 
37].  Many  full-featured  programs  have  list  prices  of 
$695  or  more,  although  volume  outlets  usually  offer  much 
better  prices.  In  addition,  outstanding  no-cost  programs 
which  also  cover  these  five  areas,  among  many  others,  can 

15MicroPro  International  Corporation,  San  Rafael, 
California. 

15Lotus  Development  Corporation,  Cambridge,  Mas¬ 

sachusetts. 

1^Ashton-Tate,  Torrance,  California. 

10Hayes  Microcomputer  Products,  Inc.,  Norcross,  Geor¬ 
gia. 

15Borland  International  Inc.,  Scotts  Valley,  Califor¬ 
nia. 

*  Lotus  Development  Corporation,  Cambridge,  Mas¬ 

sachusetts. 

^1The  Software  Group,  Balls ton  Lake,  New  York. 
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be  found  in  the  public  domain,  although  some  sacrifices  in 
support,  documentation,  power,  features,  and  standard  us¬ 
age  may  have  to  be  made. 

The  selection  or  development  of  software  for  the  pro¬ 
posed  stand-alone  system  should  naturally  be  driven  by  the 
projects  for  which  the  system  is  to  be  a  tool.  Emphasis 
should  be  placed  on  those  needs  which  are  not  currently 
supported  and  will  likely  still  not  be  available  even  af¬ 
ter  the  installation  of  the  CHCS  (see  Chapter  Three).  By 
considering  currently  available  software  packages,  the  en¬ 
tire  stand-alone  system  can  be  developed  as  quickly  as  the 
military  procurement  system  allows,  and  be  provided  with 
software  which  has  already  been  tested  and  documented. 
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CHAPTER  V 

JUSTIFICATION 


Despite  all  the  nice  things  that  can  be  said  about 
having  a  stand-alone  microcomputer  system  available  in  the 
laboratory,  tangible  benefits  must  be  documented  to  jus¬ 
tify  its  acquisition.  After  having  shown  the  need  for  the 
system  to  exist  (Chapter  Three)  and  that  the  proposed 
microcomputer  can  fulfill  the  need  (Chapter  Four),  some 
discussion  must  take  place  regarding  its  relative  worth. 
Since  the  common  denominator  of  worth  to  the  government  is 
money,  a  translation  of  benefits  to  dollars  must  usually 
take  place.  However,  this  opens  the  door  to  individual 
interpretations.  How  much  more  is  the  value  of  a  word 
processor,  for  example,  to  a  poor  typist  as  opposed  to  a 
good  one,  all  else  being  equal?  Using  a  conventional 
typewriter,  the  good  typist  will  likely  make  fewer  errors, 
and  he  will  have  to  invest  much  less  of  his  time  in  redo¬ 
ing  any  given  error.  Therefore,  the  word  processor  be¬ 
comes  more  justifiable  (worth  more  dollars)  to  the  poorer 
typist,  but  the  machine  and  its  associated  costs  are  iden- 
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quantities  with  specific  value  judgments  will  be  avoided 
in  this  paper;  the  inherent  differences  among  laboratories 
and  their  staffs,  however  small  these  differences  may  be, 
will  vary  the  relative  worths  of  their  respective  comput¬ 
ers. 

Although  the  worth  of  a  given  laboratory  microcom¬ 
puter  can  best  be  determined  by  the  local  management,  even 
general  data  can  be  used  to  show  that  the  cost  of  such  a 
system  can  be  quickly  recaptured  in  essentially  every  lab¬ 
oratory  based  on  time  savings  alone.  In  a  typical  small 
laboratory,  a  $3,000  microcomputer  system  can  pay  for  it¬ 
self  in  the  first  year  by  saving  each  staff  member  an  av¬ 
erage  of  less  than  5  minutes  per  day^-.  Reaching  a  general 
monetary  break-even  point  will  not  take  more  than  a  year 


*A  Captain  with  5  years  of  service  receives  approxi¬ 
mately  $38,784.05  in  total  annual  compensation  [13,  p.  1] . 
If  the  laboratory  also  has  14  technicians  and  each  is  as¬ 
sumed  to  be  compensated  at  only  half  the  rate  of  the  Cap¬ 
tain  (very  conservative),  total  annual  compensation  for 
the  laboratory  is  $310,272.40.  Depending  on  the  year  and 
how  each  staff  member  chooses  to  take  his  leave  time,  he 
may  work  from  219  to  251  days  in  a  year;  the  mean  is  235 
days.  Authorized  absences  other  than  leave,  such  as  TDY 
and  sick  time,  are  not  considered.  Hence,  the  laboratory 
works  3,525  person-days  in  a  typical  year,  or  28,200  per¬ 
son-hours  if  an  8-hour  day  is  assumed  (seldom  factual,  but 
sufficient  for  comparison),  thereby  averaging  about  $11.00 
per  hour.  It  therefore  requires  about  272.7  person-hours 
of  work  to  make  $3,000,  or  about  4  minutes  and  39  seconds 
per  person  for  each  of  235  days  [19,  pp.  MC43-050-107  - 
MC43-050-108) . 


or  two  for  any  laboratory,  and  will  frequently  be  attained 
much  sooner. 


System  Alternatives 

Although  many  of  the  requirements  of  different  labo¬ 
ratories  for  microcomputer  support  are  alike,  laboratory 
sizes  and  scopes  vary  greatly.  As  a  result,  the  configu¬ 
ration  of  the  stand-alone  system  may  also  vary  according 
to  the  differences  in  size  and  scope  of  the  requirements. 
In  addition,  more  than  one  microcomputer  may  be  required, 
and  if  so,  it  may  be  necessary  to  link  them  together  into 
a  network.  Careful  consideration  of  the  mission  of  the 
individual  laboratory,  as  well  as  the  duties  and  prefer¬ 
ences  of  its  staff,  must  be  a  part  of  the  system  design 
process. 

In  much  the  same  way  as  the  addition  of  options  to  a 
car  make  it  much  more  useful  and  pleasant  to  drive  than 
another  which  is  outwardly  identical,  the  performance  (and 
price)  of  a  microcomputer  is  greatly  affected  by  the  in¬ 
stalled  extras.  The  standard  IBM  PC,  PC/XT,  or  compatible 
of  just  three  years  ago  is  no  longer  sufficient  to  handle 
the  needs  of  most  users.  The  dramatic  decrease  in  price 
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of  memory  chips  in  the  last  18  months  has  made  the  64K2 
and  even  256K  machines  less  common,  since  the  cost  of  ex¬ 
pansion  to  the  (present)  limit  of  MS-DOS  or  PC-DOS 
(hereafter  referred  to  simply  as  DOS)  of  640K  is  extremely 
reasonable.  With  more  memory  came  the  need  for  more  stor¬ 
age  space,  and  most  computers  are  now  configured  with  at 
least  two  360K  floppy  diskette^  drives.  Today,  hard  disk 
drives,  also  known  as  fixed  disks,  are  very  common.  They 
typically  hold  up  to  30M*  of  data  and  are  about  twenty 
times  faster  than  floppies.  Since  added  memory  and  storage 
are  usually  much  less  expensive  than  the  cost  of  highly 


2k  is  a  symbol  for  the  prefix  kilo-,  meaning  103  or 
1,000.  In  computer  jargon,  it  is  often  written  as  K  when 
there  is  no  possibility  of  confusion  with  degrees  Kelvin. 
Since  computers  are  binary,  the  computer  K  actually  de¬ 
notes  210  or  1,024.  Unless  otherwise  specified,  the  prod¬ 
uct  refers  to  a  number  of  bytes,  each  consisting  of  8  bits 
(binary  digits — Os  or  Is),  and  may  also  be  written  as  kb, 
kB,  or  KB.  A  byte  can  be  thought  of  as  the  amount  of  mem¬ 
ory  required  to  store  one  character  of  information. 

^Floppy  diskettes,  also  known  as  floppies  or  disks 
when  no  confusion  can  result,  are  the  familiar  5.25-inch 
nonrigid  disks  used  by  most  MS-DOS  computers.  When  for¬ 
matted  under  versions  2.0  and  later  of  DOS,  each  disk  con¬ 
tains  a  maximum  of  2  sides  of  40  tracks  each  of  9  sectors 
each  of  512  bytes  each,  for  a  total  of  360K  (368,640 
bytes)  of  storage.  Some  of  the  space  is  used  by  DOS  for 
housekeeping,  leaving  354K  (362,496  bytes)  of  usable  disk 
space. 

*This  is  a  symbol  for  the  prefix  mega-,  denoting  10^. 
The  computer  M  means  220  or  1,048,576  and  is  used  in  the 
same  way  as  K. 
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optimized  software,  much  of  the  newest  software  is  being 
written  with  the  assumption  that  the  extra  operating  space 
will  be  present;  indeed,  many  packages  require  it.  Sym¬ 
phony,  for  example,  requires  at  least  a  320K  system  with 
two  floppy  drives  or  one  floppy  drive  and  a  hard  drive; 
the  latter  is  recommended  [17,  p.  45]. 

Although  technically  considered  an  option,  including 
a  printer  in  the  system  is  an  absolute  necessity  in  light 
of  the  established  importance  of  word  processing  capabili¬ 
ties  in  the  stand-alone  system.  On  the  other  hand,  the 
ability  to  com.nunicate  with  other  computers  over  standard 
transmission  lines  (including  Autovon5)  requires  the  pres¬ 
ence  of  a  modem  and  software  to  support  it.  The  value  to 
a  laboratory  of  having  instantaneous  access  to  data  from 
any  other  laboratory  or  from  another  computer  must  be 
carefully  weighed.  Since  more  and  more  military  laborato- 
rians  are  being  trained  in  computer  technology,  and  still 
more  are  already  familiar  with  DOS  systems,  it  is  antici¬ 
pated  that  there  will  be  many  programs  written  by  local 
personnel.  Programs  written  in  this  way  are  in  the  public 


^Autovon  is  an  acronym  for  the  Automatic  Voice  Net¬ 
work,  a  system  of  telephone  lines  maintained  by  the  DoD 
which  connects  most  military  telephones  throughout  the 
world  and  thus  permits  easy  and  relatively  inexpensive 
global  telephone  communications. 
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domain  of  other  government  agencies  and  access  to  them 
would  become  important.  Including  a  modem  in  the  labora¬ 
tory  system,  then,  is  strictly  optional,  but  it  would 
likely  soon  become  sorely  missed  if  foregone. 

Several  haidware  options  do  little  to  alter  the  un¬ 
derlying  abilities  of  the  microcomputer  system,  but  never¬ 
theless  may  be  great  conveniences  and  serve  to  make  human 
interfacing  more  effective.  An  example  of  such  a  conve¬ 
nience  is  the  inclusion  of  a  clock  which  keeps  time  con¬ 
tinuously  (even  when  the  system  is  off  or  disconnected  by 
use  of  a  rechargeable  battery)  and  automatically  loads  the 
proper  time  and  date  into  DOS  when  the  system  is  started, 
eliminating  the  need  for  manually  entering  this  data  every 
time.  Another  example  is  the  selection  of  a  screen  dis¬ 
play.  Options  include  a  monochrome  adapter,  a  standard 
color  graphics  adapter  (CGA) ,  and  an  enhanced  color  graph¬ 
ics  adapter  (EGA),  along  with  an  appropriate  monitor.  At 
least  one  of  the  display  options  must  be  included,  of 
course,  but  the  one  selected  is  largely  left  to  the  dis¬ 
cretion  of  the  users.  Selection  of  the  EGA  system  will 
offer  the  most  utility  in  the  future,  though. 


System  Availability 

In  keeping  with  the  premise  upon  which  this  paper  is 
based,  no  piece  of  hardware  or  software  which  is  not  a 
current  "off-the-shelf"  product  has  been  considered  as  an 
option.  In  this  sense,  availability  refers  to  the  likeli¬ 
hood  of  successfully  obtaining  the  desired  system  and  its 
options  under  the  constraints  of  the  military  procurement 
system.  It  also  refers  to  the  likelihood  of  the  procured 
system  components  operating  properly  in  concert  with  one 
another . 

A  great  step  toward  relatively  easy  access  to  micro¬ 
computer  systems  was  taken  with  the  letting  of  the  previ¬ 
ously  mentioned  standard  requirements  contract  with  Zenith 
Data  Systems.  Although  justification  is  still  required, 
many  of  the  bureaucratic  evaluation  and  approval  processes 
previously  associated  with  microcomputer  purchases  have 
already  been  accomplished  and  need  not  be  repeated.  It  is 
conceivable  that  the  purchase  of  such  a  system  may  now  be 
no  more  involved  than  that  of  a  new  analytical  laboratory 
instrument.  With  this  in  mind,  it  is  all  the  more  impor¬ 
tant  to  order  the  computer  eilready  outfitted  with  the  de¬ 
sired  options  rather  than  having  to  justify  individual 
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purchases  of  software,  expansion  boards,  and  peripheral 
equipment  later  on. 

It  is  important  to  note  that  add-in  hardware  is 
available  from  many  manufacturers  and  the  equipment  is 
necessarily  different.  Software  packages,  however,  are 
written  to  run  on  particular  types  of  hardware  and  may  not 
support  that  of  certain  manufacturers.  Although  software 
developers  make  every  effort  to  support  the  most  popular 
types  of  hardware,  there  are  a  few  names  which  are  ubiqui¬ 
tously  supported.  Although  a  higher  price  is  generally 
associated  with  these  names,  they  have  become  industry 
standards  and  compatibility  with  the  software  packages  the 
laboratory  selects  is  virtually  assured.  Obvious  examples 
of  these  standards  are  IBM  for  computers,  Epson®  for 
printers,  and  Hayes7  for  modems.  Many  companies  emulate 
these  standards  and  claim  to  be  compatible,  but  extreme 
care  should  be  exercised  when  considering  such  a  purchase. 


®Epson  America,  Inc.,  Torrance,  California. 

7Hayes  Microcomputer  Products,  Inc.,  Norcross,  Geor¬ 
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Relative  Cost 


To  compare  the  cost  of  a  microcomputer  with  that  of  a 
large  integrated  laboratory  information  system,  such  as 
the  CHCS,  is  neither  fair  nor  useful.  Obviously,  the 
smaller  system  will  cost  a  great  deal  less,  but  there  is 
no  intention  of  using  it  to  replace  the  larger  one.  Al¬ 
though  each  system  can  likely  mimic  the  other  to  some  de¬ 
gree,  the  designs  are  intended  to  complement  each  other. 
It  would  make  more  sense  to  include  the  microcomputer  sys¬ 
tems  in  the  total  cost  of  the  CHCS,  but  this  will  cer¬ 
tainly  not  happen.  Laboratories  will  be  forced  to  deal 
with  the  cost  of  the  small  systems  on  their  own. 

A  great  deal  of  money  can  be  saved  by  purchasing 
hardware  clones,  providing  nothing  is  lost  due  to  incom¬ 
patibility  problems  as  discussed  previously.  The  advanced 
Zenith  system,  for  example,  at  $1,658  [1,  p.  8]  will  be 
roughly  one  third  the  cost  of  a  comparably  equipped  IBM 
system.  In  addition,  the  identical  item  is  often  avail¬ 
able  at  a  greatly  reduced  price  from  certain  suppliers. 
To  assume  that  the  published  list  price  of  a  piece  of 
hardware  or  software  is  representative  of  the  actual  price 
is  naive.  WordStar  Professional,  for  example,  has  a  list 
price  of  $495  (14,  p.  96]  but  can  be  obtained  for  as  lit- 
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tie  as  $230  from  some  distributors  and  for  $130  from  the 
standard  requirements  contract  [1,  p.  37].  A  similar  cost 
differential  is  usually  associated  with  hardware  as  well. 

System  Utility 

Although  the  idea  of  flexibility  has  already  been 
mentioned  as  a  key  positive  aspect  of  a  stand-alone  labo¬ 
ratory  information  system,  it  bears  reiteration  here  as 
part  of  the  justification.  The  avenues  by  which  the  labo¬ 
ratory  staff  can  take  advantage  of  an  open  system  must  be 
addressed. 


Management  Options 

The  management  has  total  control  of  the  microcomputer 
information  system,  within  the  confines  of  the  Air  Force 
regulations.  Management  is  free  to  select  and  use  the 
software  and  hardware  which  they  feel  will  be  most  produc¬ 
tive  for  the  given  laboratory  and  staff.  Databases  can  be 
designed  to  in-house  specifications  and  need  contain  only 
locally  relevant  information.  Only  if  the  data  are  in¬ 
tended  to  be  shared  need  they  conform  to  any  previously 
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defined  specifications,  which  can  easily  be  set  apart  ei¬ 
ther  through  regulation  or  informal  agreement. 

The  other  advantage  of  total  management  control  is 
the  independence  a  stand-alone  system  offers.  The  system 
will  not  be  tied  up  gathering  data  from  instruments,  un¬ 
less  these  interfaces  are  deemed  useful,  and  will  hence  be 
available  for  use  when  needed.  Access  to  the  system  can 
be  controlled  by  the  laboratory  management,  including  any 
prioritizing  required.  And  the  time  may  come  when  the 
laboratory  management  will  be  given  sufficient  authority 
over  access  and  job  authorization  that  the  system  can  be 
utilized  to  its  fullest. 

Use  of  Local  Computer  Expertise 

Although  relatively  few  have  been  formally  trained  in 
computer  operations,  there  can  be  no  doubt  that  many  labo- 
ratorians  are  familiar  with  computers.  Because  of  the 
standard  set  by  MS-DOS  machines,  many  of  these  persons  are 
particularly  adept  at  handling  IBM  PCs  and  their  compati¬ 
bles.  This  fact  alone  represents  a  tremendous  resource 
already  available  to  laboratory  management  which  remains 
untapped  until  the  proper  tools  are  available.  Eventu¬ 
ally,  every  Air  Force  laboratorian  will  become  knowledge- 
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able  regarding  the  CHCS  in  whatever  form  it  appears*  but 
laboratorians 1  current  abilities  with  standard  systems 
will  not  represent  a  large  asset  when  initially  dealing 
with  the  uniqueness  of  the  CHCS. 

Acquisition  Time 

Off-the-shelf  software  and  hardware  have  the  advan¬ 
tage  of  already  being  available  and  to  a  great  extent  have 
already  undergone  much  of  the  testing  and  practical  usage 
which  must  follow  the  implementation  of  a  newly  designed 
system.  As  a  result*  the  microcomputer  and  its  associated 
software  can  be  purchased  and  set  up  in  the  minimum  time 
allowed  by  regulations,  minimizing  the  likelihood  of  pre¬ 
purchase  obsolescence. 

Although  laboratory  computer  support  should  have  been 
a  part  of  the  Air  Force  years  ago*  the  first  such  support 
available  to  most  laboratories  will  be  the  CHCS.  The  in¬ 
stallation  of  the  CHCS  may  not  take  place  until  June  of 
1994  [16*  p.  G-12]  for  some  hospitals*  a  date  which  cur¬ 
rent  delays  already  threaten.  The  stand-alone  system  will 
then  serve  as  an  interim  information  system  for  these 
sites.  Properly  equipped*  these  microcomputers  will  also 
serve  as  terminals  for  limited  access  to  CHCS  systems  in 
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supporting  laboratories  when  the  first  CHCS  systems  become 
functional.  With  the  current  availability,  there  really 
exists  no  excuse  for  any  Air  Force  laboratory  not  to  have 
the  support  of  this  stand-alone  information  system  within 
a  few  months. 


hi 
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CHAPTER  VI 

IMPLEMENTATION 


Having  completed  the  analysis  of  the  stand-alone  in¬ 
formation  system  and  addressed  its  design  to  the  extent  of 
exploring  the  available  configurations*  the  physical  ef¬ 
fort  involved  in  bringing  the  concept  to  fruition  begins. 
Weinberg  calls  this  effort  the  "implementation  phase"  [44, 
p.  11].  It  deals  with  the  plans  and  activities  necessary 
to  translate  the  design  into  a  functioning  unit.  In  Air 
Force  terms,  it  means  documenting  the  analysis  and  design 
of  the  proposed  system  as  a  justified  request  for  pur¬ 
chase,  followed  by  the  requirements  to  turn  the  machine 
into  the  tool  it  was  intended  to  be. 


Acquisition 


Because  of  the  standard  requirements  contract  dis¬ 
cussed  above,  the  actual  purchase  of  the  small  computer  is 
not  much  different  from  the  purchase  of  a  piece  of  labora¬ 
tory  equipment.  However,  the  computer  is  much  less  likely 
to  exceed  the  $3,000  threshold  which  separates  normal  pur- 
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chases  from  investment  equipment.  Hence,  the  decision  and 
money  will  be  largely  controlled  in  the  local  hospital; 
the  microcomputer  will  have  to  compete  against  other 
equipment  requests  from  all  departments  in  the  hospital. 

The  actual  steps  involved  in  acquiring  the  microcom¬ 
puter  system  are  outlined  explicitly  in  AFR  700-26  [11, 
pp.  3,  5]. 

a.  Identify  a  requirement  for  which  au¬ 
tomation  may  be  appropriate.  ... 

b.  Confirm  the  operational  validity  of  the 
requirement  by  having  it  approved  at  the  appro¬ 
priate  level  in  the  user's  chain  of  command. 

c.  Contact  the  ISSO1  for  assistance  in  de¬ 
veloping  and  processing  the  requirements  docu¬ 
ment,  (ISRD^,  SON^,  AF  Form  601*)  and  identify¬ 
ing  a  potential  technical  solution.  If  the  po¬ 
tential  technical  solution  involves  a  small  com¬ 
puter  to  process  classified  data  (TEMPEST),  spe¬ 
cial  attention  must  be  paid  to  security  require¬ 
ments  and  to  developing  or  selecting  a  mainte¬ 
nance  concept  that  protects  the  TEMPEST  in¬ 
tegrity  of  the  small  computer. 

d.  Along  with  the  ISSO,  process  the  re¬ 
quirements  document  through  the  ISRB^  and,  when 


*"The  local  ISSO  [Information  System  Staff  Officer] 
is  the  base  focal  point  for  small  computer  user  assis¬ 
tance.  .  . "  [11,  p.  10]. 

^Information  Systems  Requirements  Document. 

^Statement  of  Need. 

*This  is  the  standard  requisition  form  for  equipment. 

^"All  small  computers  will  have  a  requirements  docu¬ 
ment  approved  by  an  Information  Systems  Requirements  Board 
(ISRB) "  [11,  p.  3], 


appropriate,  specify  that  a  small  computer  is 
the  preferred  technical  solution.  .  .  . 

e.  After  the  requirements  document  is  ap¬ 
proved,  begin  the  process  of  acquiring  the  small 
computer  with  assistance  from  the  local  ISSO. 

Mote  that  standard  small  computers  and  software 
on  standard  requirements  contract  are  requisi¬ 
tioned  from  the  supply  system.  Software  not  on 
standard  requirements  contracts  is  acquired 
through  normal  contractual  actions.  .  .  . 

f.  Prepare  for  delivery  by  setting  up  the 
location,  obtaining  the  required  supplies,  ar¬ 
ranging  for  training,  and  making  sure  of  compli¬ 
ance  with  appropriate  security  measures. 

g.  Enter  the  equipment  into  the  supply  in¬ 
ventory  and  automatic  data  processing  equipment 
(ADPE)  reporting  system  with  the  assistance  of 
the  local  ISSO  and  the  base  supply  Equipment 
Management  Office. 

Paragraphs  a  and  c  require  some  effort  on  the  part  of  the 
laboratory  manager.  This  paper  has  documented  several 
needs  common  to  laboratories  in  the  Air  Force,  but  has  by 
no  means  addressed  all  the  requirements  of  any  given  labo¬ 
ratory.  Indeed,  the  individual  manager  may  find  local 
needs  more  acute  than  any  discussed  or  speculated  on  here. 
Paragraphs  b  and  d  may  require  some  diplomacy  and  well-di¬ 
rected  persuasion.  Whenever  interpersonal  relationships 
come  into  play,  the  experience  of  the  individual  labora¬ 
tory  representative  becomes  paramount  in  the  success  of 
the  endeavor. 

If  the  requirements  document  specifies  the  Z-248  as 
an  appropriate  computer,  the  system  can  be  ordered  di¬ 
rectly  through  supply  channels  using  AF  Form  601  as  in 
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paragraph  e.  This  is  the  same  form  used  for  other  rela¬ 
tively  inexpensive  laboratory  equipment  and  is  outwardly 
the  easiest  and  most  familiar  route  for  a  laboratory  man¬ 
ager  to  follow.  If  for  some  reason  (which  obviously  can¬ 
not  be  identified  here)  equipment  or  software  not  offered 
on  the  standard  requirements  contract  is  needed,  other  av¬ 
enues  must  be  explored.  In  general,  however,  such  an  un¬ 
dertaking  appears  not  to  be  justified,  assuming  the  Z-248 
conforms  to  the  contractual  requirements. 

Accomplishing  these  requirements  documents  the  ap¬ 
proval  of  the  system  and  places  it  in  the  prioritized 
queue  of  requested  hospital  equipment.  At  this  point,  the 
manager's  active  and  diplomatic  participation  in  the  Local 
Purchase  Board®  will  usually  be  required  for  the  purchase 
of  the  system.  Here  again,  the  documents  produced  during 
a  proper  analysis  are  invaluable. 


® Although  it  may  be  known  by  other  titles,  each  hos¬ 
pital  periodically  convenes  a  board  of  representatives 
from  the  various  departments  of  the  hospital  to  prioritize 
the  approved  equipment  requests  for  purchase.  Medical  ur¬ 
gency,  rank  of  representatives,  individual  enthusiasm,  and 
political  manipulation  all  play  a  part  in  these  sessions. 
For  all  his  efforts,  the  laboratory  representative  will 
likely  not  be  successful  in  establishing  a  stand-alone 
laboratory  information  system  if  the  available  dollar 
amount  will  not  cover  the  computer  and  the  equipment  pre¬ 
ceding  it  in  the  queue. 


93 


Assuming  that  funds  are  allocated  for  the  purchase  of 
the  system,  site  preparation  can  begin  per  paragraph  f. 
All  the  previously  discussed  considerations  for  environ¬ 
ment,  security,  and  intended  interfacing  with  humans  and 
with  instruments  must  now  be  put  into  operation.  Having 
the  site  ready  for  installation  will  make  the  transition 
much  easier  and  faster.  Delivery  speed  will  also  be  en¬ 
hanced  by  careful  monitoring  of  the  requisition  as  it 
travels  through  supply  channels.  If  each  of  several  agen¬ 
cies  takes  the  maximum  time  allowed  to  process  the  requi¬ 
sition,  much  time  will  be  lost. 

AFR  700-26  makes  it  clear  that  the  responsibility  for 
the  small  computer  system  lies  with  the  user  111,  p.  3-4], 
He  must  provide  for  its  requisition,  receipt,  setup,  test¬ 
ing,  training,  use,  and  maintenance.  As  a  result,  the 
laboratory  manager  will  be  in  charge  of  the  installation 
of  the  newly  arrived  system  with  the  assistance  of  the 
ISSO.  If  laboratory  instruments  are  to  be  interfaced  with 
it,  technical  representatives  from  the  vendors  may  have  to 
be  contacted.  In  addition,  various  requirements  regarding 
labeling  of  the  equipment,  entry  into  identification  logs, 
and  assignment  of  a  serial  number  must  be  satisfied  [11, 
p.  5]  . 


The  laboratory  staff  is  also  responsible  for  testing 

the  newly  arrived  hardware  and  software.  One  might  be  led 

to  assume  that  since  no  specific  requirement  and  little 

guidance  is  given  on  this  subject  that  it  is  relatively 

unimportant.  Burch  comments  on  this  fallacy  [4,  p.  513]. 

Testing  the  newly  developed  or  modified  system 
is  one  of  the  most  important  activities  in  the 
systems  development  methodology.  It  is  an  im¬ 
plementation  activity  that,  similar  to  training 
personnel,  requires  careful  planning  and  appli¬ 
cation.  The  goal  of  testing  is  to  verify  the 
logical  and  physical  operation  of  all  design 
blocks  to  determine  that  they  operate  as  in¬ 
tended.  Often,  testing  is  given  lip  service,  or 
is  abridged  as  cost  overruns  occur  or  schedules 
slip.  Inevitably,  failure  to  test  adequately 
leads  to  problems  with  the  systems  operation. 

Indeed,  AFR  700-26  mentions  testing  only  in  passing,  stat¬ 
ing  that  "the  tequipment  should  be  used  extensively  prior 
to  warranty  expiration  to  make  sure  it  is  in  proper  oper¬ 
ating  condition"  [11,  p.  5]. 

Since  only  off-the-shelf  hardware  and  software  are 
espoused  here,  it  is  logical  to  believe  that  all  of  it  has 
undergone  some  degree  of  aggressive  testing  already,  both 
during  development  and  through  actual  use  in  the  field. 
In  this  regard,  there  is  little  the  laboratory  manager  can 
do  to  check  the  system  other  than  running  various  diagnos- 


tic  programs  and  noting  obvious  damage.  However,  any  data 
or  software  developed  by  the  laboratory  must  be  checked 
appropriately  according  to  its  importance  to  the  user. 


Personnel  Training 


The  laboratory  will  also  be  individually  responsible 
for  any  system  training  necessary,  although  the  help  of 
the  ISSO  can  be  enlisted  [11,  p.  31.  The  tendency  in  such 
a  situation  is  to  evolve  into  a  predicament  as  described 
by  Riccabona  [34,  p.  MC55-300-101] . 

In  the  past,  microcomputer  training  had 
been  approached  on  a  purely  informal  basis. 

Users  would  teach  themselves  using  the  documen¬ 
tation  which  accompanied  the  hardware  or  soft¬ 
ware.  Since  microcomputer  users  were  typically 
knowledgeable  hobbyists,  or  a  least  enthusiastic 
about  becoming  knowledgeable,  the  standard 
user's  guide  proved  to  be  sufficient. 

Assuming  all  of  the  laboratory  staff  to  possess  the  enthu¬ 
siasm  of  a  hobbyist  is  likely  to  result  in  the  creation  of 
a  faction  in  the  laboratory  which  shuns  the  computer  alto¬ 
gether.  The  manager's  goal,  then,  is  not  only  to  teach 
the  staff  how  to  use  the  system,  but  also  to  stimulate  a 
desire  to  want  to  understand  and  use  it. 

Burch  maintains  that  "the  first  step  in  determining 
training  requirements  and  training  approaches  is  to  com- 
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pile  a  list  of  all  the  tasks  required  by  the  new  system 
and  the  skills  needed  to  perform  them"  [4,  p.  511].  Obvi¬ 
ously,  the  overall  purpose  of  the  information  system  will 
have  a  bearing  here.  If  the  system  is  interfaced  with  in¬ 
strumentation  and  is  the  heart  of  the  data  management  sys¬ 
tem  in  the  laboratory,  every  staff  member  must  be  familiar 
with  its  operation.  On  the  other  hand,  if  the  system  is 
provided  as  a  more  efficient  alternative  to  other  accept¬ 
able  methods,  such  as  word  processing,  more  latitude  can 
be  granted.  Still,  laboratory  management  will  want  to  en¬ 
courage  more  efficiency.  The  list  of  skills  will  be  most 
easily  managed  by  appending  them  to  in-house  on-the-job 
training  records  and  to  the  indoctrination  protocol  for 
newly  arrived  personnel. 

The  initial  training  forum  should  be  at  the  labora¬ 
tory  training  sessions  which  are  required  to  be  held  regu¬ 
larly.  This  cai.  begin  long  before  the  arrival  of  the  com¬ 
puter,  in  much  the  same  way  as  the  staff  discusses  in  ad¬ 
vance  the  need  for  and  use  of  a  new  laboratory  instrument. 
Many  unpleasant  surprises  can  be  avoided  in  this  way. 

Upon  arrival  of  the  equipment,  hands-on  training 
schedules  can  begin.  One  of  the  advantages  of  a  stand¬ 
alone  system  is  its  independence.  Within  reasonable  limi¬ 
tations,  the  user  is  free  to  experiment  without  worry  of 
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causing  significant  damage*  Tutorials  provide  an  enjoy¬ 
able  atmosphere  for  learning,  and  the  framers  of  the 
Zenith  contract  wisely  mandated  that  these  be  provided  [1, 
pp.  85-87 ] . 

The  contractor  shall  provide  technical  services 
and  materials  to  train  Government  personnel. 
Contractor  must  provide  a  Computer  Assisted  In¬ 
struction  (CAI)  package.  ...  CAI  courses  must 
be  delivered  on  5.25-inch  floppy  disks,  interac¬ 
tive,  and  user  friendly.  Each  course  must  be 
supplied  with  the  normal  commercial  documenta¬ 
tion.  Students  taking  these  courses  will  be 
functional  users  with  little  or  no  computer  ex¬ 
pertise. 

The  costs  for  the  courses  mentioned  are  very  reasonable 
and  their  successful  completion  by  each  staff  member  pro¬ 
vides  a  convenient  documentation  method  for  training 
records.  In  addition,  the  initial  heavy  use  of  the  com¬ 
puter  system  effected  by  the  mandatory  completion  of  the 
tutorials  provides  an  excellent  testing  medium  for  the  new 
system. 


Conversion  from  Current  Methods 


Although  relatively  few  medical  technologists  or 
technicians  have  any  fear  or  anxiety  associated  with  com¬ 
puters  or  automation,  many  exhibit  a  definite  resistance 
to  change.  Encouraging  the  use  of  the  new  system  instead 
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of  older  routines  with  which  the  staff  members  have  become 
comfortable  may  present  a  unique  challenge  to  the  labora¬ 
tory  management.  It  is  important  to  initiate  the  change 
to  the  new  system  by  having  a  workable  conversion  plan  be¬ 
fore  the  new  system  is  installed.  The  success  of  the  con¬ 
version  will  have  a  major  bearing  on  the  credibility  of 
the  system  and  the  impression  it  leaves  with  the  labora¬ 
tory  staff. 

There  are  various  ways  to  approach  change  from  one 


system  to  another,  each  with  advantages  and  disadvantages 
and  each  being  better  suited  to  some  situations  than  oth¬ 
ers.  Four  basic  conversion  methods  are  outlined  by  Burch 
[4,  pp.  522-524]. 


1.  Direct  Conversion.  A  direct  conversion  is 
the  implementation  of  the  new  system  and  the  im¬ 
mediate  discontinuance  of  the  old  system,  some¬ 
times  called  the  "cold  turkey"  approach.  .  .  . 

2.  Parallel  Conversion.  Parallel  conversion  is 
an  approach  wherein  both  the  old  and  the  new 
system  operate  simultaneously  for  some  period  of 
t ime .... 

3.  Modular  Conversion.  Modular  conversion, 
sometimes  termed  the  "pilot  approach,"  refers  to 
the  implementation  of  a  system  into  the  organi¬ 
zation  on  a  piecemeal  basis.  .  .  . 

4.  Phase-in  Conversion.  The  phase-in  approach 
is  similar  to  the  modular  approach.  This  ap¬ 
proach  differs,  however,  in  that  the  system  it¬ 
self  is  segmented,  and  not  the  organization. 

Of  these  approaches,  direct  conversion  is  most  likely  to 

fail  and  neither  modular  nor  phase-in  conversion  fit  well 
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in  a  single-laboratory  setting.  Parallel  conversion  is 
the  best  candidate  since  it  conforms  to  other  conversion 
processes  with  which  the  laboratory  is  already  familiar, 
such  as  conversion  to  a  new  lot  of  reference  standards.? 
Indeed,  documentation  of  the  temporary  duplication  of  ef¬ 
fort  serves  to  test  the  system  in  the  same  way  that  the 
output  of  a  new  laboratory  instrument  must  be  reconciled 
with  the  previous  results.  It  also  offers  the  staff  the 
opportunity  of  seeing  the  advantages  of  the  computer  sys¬ 
tem  over  the  previous  methods. 

Because  the  user,  in  this  case  the  laboratory  man¬ 
ager.  has  the  primary  responsibility  for  implementing  a 
small  computer  system  in  the  Air  Force  setting,  all  of  the 
associated  activities  are  his  to  perform.  He  may  or  may 
not  have  the  assistance  of  an  individual  experienced  in 
setting  up  small  laboratory  systems.  With  this  in  mind, 
Burch  emphasizes  the  importance  of  parallel  conversion  [4, 
p.  523]. 

.  .  .  Conversion  projects  are  often  bur¬ 
dened  with  additional  tasks  of  training,  test¬ 
ing,  procedure  and  documentation  rewrites,  file 


?When  a  new  lot  of  reference  material  is  received,  it 
is  repeatedly  tested  as  a  sample  using  the  old  lot  as  the 
reference.  By  documenting  that  the  tested  values  of  the 
new  lot  correspond  to  their  stated  values  based  on  the  old 
lot,  continuity  of  the  testing  environment  from  one  lot  to 
the  next  is  shown.  This  is  known  as  parallel  testing. 


changes,  attempts  at  retrofitting  controls,  and 
major  computer  configuration  adjustments.  If 
this  is  the  case,  then  parallel  conversion  is 
really  the  only  sensible  approach  to  use. 

Maintenance 

As  with  any  other  laboratory  instrument,  the  stand¬ 
alone  information  system  must  be  maintained  in  conformance 
with  established  standards.  Documentation  of  this  mainte¬ 
nance  must  satisfy  the  requirements  of  the  Air  Force  as 
well  as  those  of  the  agencies  granting  accreditation  to 
the  laboratory. 

Air  Force  maintenance  requirements  are  relatively 
simple  but  not  yet  completely  standard.  Essentially, 
"maintenance  concepts"  are  developed  at  the  MAJCOM  level. 
Local  ISSOs  develop  procedures  to  implement  the  concepts 
and  monitor  the  users'  compliance  with  the  procedures  [11. 
p.  6].  Special  considerations  are  given  to  computers  han¬ 
dling  classified  data.  The  thrust  of  these  procedures  is 
obtaining  service  when  the  system  is  down. 

Whether  th^  laboratory  purchases  a  maintenance  con¬ 
tract  for  the  system  must  be  decided  based  on  the  reliance 
of  the  laboratory  on  the  computer  or  software,  the  cost, 
and  the  availability  of  repairs  locally.  The  Zenith  con- 
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tract  allows  purchasers  of  these  systems  to  obtain  repair 
service  in  any  of  three  ways  and  the  cost  for  each  is  very 
reasonable.  Typically#  a  postwarranty  maintenance  con¬ 
tract  for  a  laboratory  instrument  costs  10  to  20  percent 
of  the  purchase  price  annually.  Under  the  Zenith  con¬ 
tract#  on-site  service  costs  $135.00  for  the  advanced  sys¬ 
tem  with  a  purchase  price  of  $1658.00#  or  about  8  percent. 
Mail-in  service  for  the  same  system  costs  $44.00;  the  user 
can  also  maintain  the  system  himself  using  spare  parts  and 
telephone  assistance  [1#  pp.  8,  83-84,  87-88], 

In  addition  to  repair  procedures#  the  laboratory 
maintenance  procedure  should  include  all  recommended  main¬ 
tenance  in  the  operations  and  technical  reference  manuals 
as  well  as  the  rules  of  common  sense  discussed  in  Chapter 
Four.  Instructions  for  performing  and  documenting  peri¬ 
odic  activities#  such  as  running  the  diagnostic  programs, 
routine  cleaning#  and  creating  backups#  must  be  included. 
The  laboratory  environment  may  necessitate  certain  preven¬ 
tive  maintenance  activities  be  performed  more  frequently 
than  the  minimum  recommended  in  the  references.  Also#  the 
amount  of  use  the  system  sustains  will  be  a  factor;  unnec¬ 
essary  cleaning  of  the  read/write  heads  of  a  floppy  disk 
drive,  for  example#  can  be  as  damaging  as  running  them 
dirty. 
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Software  and  data  maintenance  also  includes  many  com- 
mon-sense  activities.  Foremost  among  these  activities  is 
to  establish  and  hold  to  a  rigorous  backup  program.  Orig¬ 
inal  program  disks  should  never  be  used  for  routine  opera¬ 
tions.  The  specifications  for  the  Zenith  contract  require 
an  unlimited  number  of  identical  copies  of  the  original 
software  may  be  produced  and  that  the  copies  operate  "in 
the  same  environment  and  independent  of  the  originally 
supplied  materials"  [1,  p.  61].  This  obvious  advantage 
may  not  be  available  if  software  is  procured  from  other 
sources,  however.  Also,  procedures  must  be  established  to 
assure  that  users  understand  and  adhere  to  the  proper  han¬ 
dling  and  storage  of  diskettes. 


103 


CHAPTER  VII 

CONCLUDING  REMARKS 

Conclusions 


In  the  course  of  this  study,  several  of  the  author's 
previous  impressions  have  been  substantiated.  The  concept 
of  the  military  providing  computerized  hospital  informa* 
tion  systems  on  a  worldwide  basis  in  and  of  itself  is 
highly  laudable  and  more  than  worthy  of  continued  pursuit. 
However,  past  efforts  have  indeed  been  directed  too  much 
at  development  and  not  enough  at  usefulness.  Time  and 
money  have  been  wasted  for  various  reasons,  not  all  of 
which  can  be  attributed  to  DoD  faults.  Lack  of  Congres- 
sional  support,  crossed  purposes,  too  much  or  too  little 
leadership,  and  a  lack  of  involvement  of  the  end  users 
have  all  contributed  to  inadequate  analysis  and  implemen¬ 
tation.  The  resulting,  embarrassing  travesty  is  that  af¬ 
ter  twenty  years  and  billions  of  dollars,  only  a  tiny  per¬ 
centage  of  military  laboratorians  have  any  computer  sup¬ 
port  at  all  in  their  work  today.  Furthermore,  the  little 
support  that  is  available  is  incomplete  and  inflexible. 
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Fortunately,  these  shortcomings  have  not  been  en¬ 
tirely  without  benefits  and  some  very  positive  attitudes 
toward  potential  systems  have  been  developed  by  the  au¬ 
thor.  TRILAB  is  the  result  of  some  of  the  lessons  learned 
in  the  past  and,  with  some  exceptions,  functions  well. 
The  VADHCP  is  also  a  good  system,  despite  its  unorthodox 
development.  The  fact  that  it  may  satisfy  the  FDs  for  the 
CHCS  speaks  very  highly  of  the  system.  Although  the  CHCS 
still  exists  only  on  paper,  it  is  impressive.  Perceived 
or  actual  weaknesses  of  previous  systems  appear  to  have 
been  specifically  addressed.  The  author  is  genuinely  ex¬ 
cited  and  looks  forward  to  its  implementation. 

But,  no  current  or  foreseeable  integrated  package  can 
anticipate  all  the  needs  of  every  laboratory  it  is  in¬ 
tended  to  support.  That  day  may  come.  Until  then,  the 
individual  laboratory,  with  its  own  technologists  and 
technicians,  must  deal  with  the  unusual  or  unsupported 
situations  as  best  it  can.  It  is  here  that  the  intelli¬ 
gence  of  the  end  user  becomes  the  most  valuable  resource 
in  the  Air  Force.  To  contend  with  these  situations  re¬ 
quires  that  the  person  be  in  control  and  be  able  to  wield 
the  tools  given  him  in  the  way  he  reasons  to  be  most  ad¬ 
vantageous  . 
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After  all  the  research  associated  with  this  paper. 


the  author  is  more  convinced  than  ever  that  stand-alone 


information  systems  based  on  standard  microcomputers  is  an 


absolutely  indispensable  tool  for  the  laboratorian.  It 


cannot  and  should  not  replace  the  large  integrated  system 


represented  by  the  CHCS.  Laboratory  support  is  only  a 


small  part  of  the  CHCS*  the  stand-alone  system  is  to  be 


totally  dedicated  to  the  laboratory.  Nevertheless,  until 


the  CHCS  is  in  place,  the  stand-alone  system  is  capable  of 


handling  most  of  the  laboratory  functions  of  the  CHCS. 


Based  on  this  research,  it  is  concluded  that  the  lab¬ 


oratory  is  best  served  by  adhering  to  the  standard  re¬ 


quirements  and  obtaining  the  advanced  computer  system  as 


described  in  the  standard  requirements  contract.  This  pa¬ 


per  has  shown  that  such  a  system  is  capable  of  operating 


efficiently  in  a  medical  laboratory  environment  and  of 


filling  many  of  the  voids  left  by  the  current  and  proposed 


integrated  systems.  It  should  be  augmented  with  whatever 


hardware  and  software  is  deemed  appropriate,  using  knowl¬ 


edge  of  local  needs,  solicited  expert  laboratory  advice. 


and  this  paper  as  guidelines.  These  augmentations  include 


support  for  word  processing,  cost  analysis,  research,  in¬ 


struction,  and  many  other  applications  which  the  users  can 


derive  as  needed.  The  system  can  be  obtained,  imple- 
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mented,  and  maintained  in  much  the  same  way  as  other  labo¬ 
ratory  equipment  and  for  a  very  reasonable  price,  which 
can  easily  be  justified  based  on  time  savings  alone. 


Recommendations  for  Further  Research 


As  further  enhancements  are  considered  for  the  CHCS 
or  any  future  system,  methods  by  which  the  user  can  access 
the  capabilities  of  the  system  should  be  developed.  This 
should  go  well  beyond  the  current  attempts  at  flexibility 
such  as  customized  report  generation.  Using  an  operating 
system  which  supports  the  virtual  machine  concept,  for  ex¬ 
ample,  would  allow  access  to  the  "machine”  and  selected 
data  without  affecting  any  other  operations. 

Finally,  the  needs,  ideas,  and  suggestions  of  the 
laboratorians  must  be  ascertained.  To  involve  every  one 
of  them  in  the  complete  analysis  process  is  impossible, 
but  surveys  can  be  conducted  at  various  points  in  the  pro¬ 
cess.  Beginning  with  the  evaluations  of  the  CHCS  upon  its 
initial  installation,  comments  from  its  new  users  should 
be  solicited,  compiled,  and  studied.  The  insight  so 


gained  will  not  only  supply  information  which  will  be 
valuable  in  a  future  analysis,  but  will  identify  individu¬ 
als  who  have  previously  unknown  computer  expertise.  The 


^  ^<r-. 


107 

pool  of  Pathologists,  Medical  Technologists,  and  Clinical 
Laboratory  Technicians  constitutes  the  greatest  clinical 
pathology  database  available  to  the  Air  Force,  and  must  no 
longer  remain  untapped. 
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